Testing at hackathons gets a bad rap. People think it means slow development, massive test suites, and boring work. That’s wrong. The right kind of testing actually saves time, prevents embarrassing demos, and helps you ship code you’re proud of.
The key word is “right kind.” You don’t need 100% code coverage at a 48-hour hackathon. You need targeted testing that catches the bugs that would actually ruin your demo.
The 80/20 rule applies perfectly: 80% of the value comes from testing 20% of your code.
Always test:
Usually skip:
The testing priority pyramid:
/\
/ \ Manual testing (demo flow)
/ \
/ E2E \ One end-to-end test
/________\
/ \ Integration tests (API endpoints)
/ \
/______________\ Unit tests (critical logic only)
The “what would embarrass me” test: If a bug showing up during your demo would embarrass you, test it. If not, maybe skip it.
You don’t need Selenium for hackathon testing. A systematic manual approach catches most issues.
The 10-minute testing checklist:
Authentication:
Core features:
Data integrity:
UI/UX basics:
Edge cases to check:
The “break your own app” session:
Set aside 30 minutes to try to break your app. Click every button twice, submit empty forms, navigate backwards, open in multiple tabs, clear cookies, resize the browser, turn off WiFi, check the console for errors.
The buddy system:
Pair up with another team and test each other’s apps. Fresh eyes catch bugs you’ve become blind to. Give them 15 minutes to sign up, use the main feature, try something unexpected, and tell you what confused them.
Generic data like “test user 1” and “Lorem ipsum” screams “we built this 20 minutes ago.” Realistic data says “we built something real.”
The realistic data formula:
The seed script approach:
Write a script that creates all demo data in one go. It should be idempotent (run multiple times without duplicates), use realistic data, create relationships, and include variety.
Example for a task management app:
{
"users": [
{"name": "Sarah Chen", "email": "sarah@startup.io", "role": "Product Manager"},
{"name": "Marcus Johnson", "email": "marcus@startup.io", "role": "Lead Developer"}
],
"tasks": [
{"title": "Design new landing page", "status": "in_progress", "priority": "high"},
{"title": "Fix authentication bug", "status": "completed", "priority": "critical"}
]
}
Visual data tips: Use real profile pictures (pravatar.cc), write 2-3 sentences of actual description, include formatting, use realistic dates.
The “just enough” principle: 5-10 records per collection is usually enough. Enough to show it works with multiple items, not so much judges scroll forever.
“It works on my machine” is the most dangerous excuse at a hackathon. If your code only works on your laptop, you have a problem.
The environment variable problem:
Never hardcode configuration. Use environment variables for API keys, database URLs, feature flags, and external service URLs.
# .env (NEVER commit this file)
DATABASE_URL=postgresql://localhost:5432/myapp
API_KEY=sk_live_abc123
// Loading environment variables
const dbUrl = process.env.DATABASE_URL;
Always include a .env.example showing what variables are needed without actual values.
The dependency problem:
.nvmrc or runtime.txtpackage-lock.json or poetry.lockThe Docker solution:
Docker is the nuclear option. If you Dockerize your app, it works everywhere.
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD ["npm", "start"]
Now anyone can run docker-compose up regardless of what’s installed on their machine.
The demo day environment checklist:
.env.example is up to dateYou don’t need to test every browser on every OS. You need to catch issues that would embarrass you during a demo.
Browser priority list:
Common cross-browser issues:
new Date('2024-03-15') works differently across browsers)The quick browser test: 5 minutes per browser — open app, log in, use main feature, check layout, check console.
The mobile browser test: Check tap targets are 44x44px, text is readable without zooming, forms are thumb-usable, layout doesn’t break, navigation works.
API bugs silently kill hackathon demos. Your frontend looks perfect, but the API returns unexpected data.
Postman/Insomnia testing checklist:
For each endpoint, test with valid data, invalid data, missing data, edge cases (empty strings, long strings, special characters), and verify authentication and authorization work.
Response validation:
Don’t trust API responses blindly. Validate in your frontend:
const data = await response.json();
if (!data.users || !Array.isArray(data.users)) {
throw new Error('Invalid API response');
}
The API mock strategy:
If your API isn’t ready, mock it. Create a simple server returning predictable data so frontend teams can work while backend finishes.
The error handling pattern:
async function fetchUsers() {
try {
const response = await fetch('/api/users');
if (!response.ok) throw new Error(`HTTP ${response.status}`);
return await response.json();
} catch (error) {
showError('Unable to load users. Please try again.');
return getCachedUsers(); // Fallback
}
}
Hackathon demos don’t face massive traffic, but 3-5 judges using your app simultaneously can cause problems if you have bottlenecks.
Common bottlenecks: Database connections (each user opens one), API rate limits, memory usage, file uploads.
Quick load testing:
# Artillery (Node.js)
artillery quick --count 10 --num 5 http://localhost:3000/api/users
# Apache Bench
ab -n 100 -c 10 http://localhost:3000/
The “friends test”: Invite 5-10 friends to use your app simultaneously. Ask them to sign up, create items, browse around, and report errors. Catches most real-world issues.
Prevention tips: Use connection pooling, add caching, set rate limits, use a CDN for static assets, optimize database queries.
30 minutes before demo:
15 minutes before:
5 minutes before:
The “disaster recovery” plan:
If something breaks during demo:
Not all bugs are equal. Triage quickly.
P0 — Fix immediately: App crashes, data loss, security vulnerabilities, authentication completely broken.
P1 — Fix before demo: Main feature broken, obvious visual glitches, broken navigation, incorrect data display.
P2 — Fix if time permits: Minor UI issues, edge case bugs, slow performance, inconsistent styling.
P3 — Work around or ignore: Cosmetic issues, rare edge cases, non-demo features, nice-to-haves.
The “fix or workaround” decision:
Common workaround patterns: Hardcode values, pre-populate data, disable broken features, use mock data, redirect to working pages.
The “ship it” decision: Sometimes the best decision is shipping with known bugs. If it’s minor, won’t be noticed, and fixing risks introducing worse bugs, document it and move on.
You don’t need a full test suite. A few targeted automated tests catch bugs you’d otherwise miss.
The smoke test script:
async function testAPI() {
const health = await fetch('/api/health');
if (!health.ok) throw new Error('Health check failed');
const user = await fetch('/api/users', {
method: 'POST',
body: JSON.stringify({ name: 'Test User', email: 'test@test.com' }),
headers: { 'Content-Type': 'application/json' }
});
if (!user.ok) throw new Error('Create user failed');
console.log('All tests passed!');
}
Takes 10 minutes to write, saves hours of debugging.
The “visual regression” trick: Take screenshots at key states, compare before demo day. If anything looks different, investigate.
The “API contract” test: Verify your API returns expected data structure:
const data = await response.json();
if (!Array.isArray(data.users)) throw new Error('Users should be an array');
if (data.users.length === 0) throw new Error('Should have at least one user');
When to use: Before major changes, before demo day, when debugging, when tired.
When to skip: Behind schedule, feature is simple, prototyping, test would be too complex.
Quick Reference: Before hackathon — set up env vars, create .env.example, write seed script. During development — test main feature after changes, run manual checklist periodically, check console. Before demo day — run full checklist, test on demo computer, verify demo data. Demo day — final smoke test 30 minutes before, open tabs, check network, take a breath, ship it.
Testing at hackathons isn’t about perfection. It’s about confidence. When you know your app works, you can focus on your presentation instead of worrying about bugs. A few targeted tests give you that confidence.