Introduction
In open-source projects, writing code is only the first step — communicating with maintainers and iterating based on their feedback is where real growth happens.
This post documents my journey contributing to the Hackathon Starter project, where I implemented and later optimized HERE Maps E2E tests in Playwright following seven rounds of feedback from the project maintainer Yasharf.
Background
- Project: Hackathon Starter
- Task: Add E2E tests for the HERE Maps API page
- Tool: Playwright
- Challenge: The initial PR worked but was inefficient and needed significant refactoring
The First Version — Functional but Inefficient
My first submission included seven test cases covering everything from page elements to map rendering.
However, it had major issues:
- Reloaded the page for every test (7× page loads)
- Checked static HTML content (titles, buttons, scripts)
- Contained repetitive logic
- Took ~15 seconds to run
7 Key Feedback Points and Improvements
1. Use a Shared Page
“Use shared page to avoid reloading for each test.”
ReplacedbeforeEachwithbeforeAllto reuse the same page instance.
✅ Result: Page loads reduced from 7 → 1 (-86%).
2–3. Remove Static Checks
“Drop static page components check.”
“Drop script version check.”
Removed unnecessary tests for static HTML and script tags — E2E tests should focus on user behavior, not layout or boilerplate.
4. Verify Exact Values
“Verify hardcoded expected values.”
Replaced fuzzy range checks (e.g., 2–4 miles) with precise expected results (toBe(2.85)).
5. Skip Error Scenario
“Skip error scenario test.”
Removed artificial error interception — such cases belong in unit or integration tests, not end-to-end.
6. Reframe API Key Test
“Frame as tiles loading test.”
Since HERE Maps uses CDN caching, invalid API keys can still load tiles from cache (returning200 OK).
Reframed the test to verify tile loading success instead of API key validity.
7. Technical Limitation — Map Details
“Check expected Seattle values (coordinates, markers, etc.).”
This was the hardest one.
Themapvariable is declared withconstinside a script block in the Pug file — making it inaccessible from Playwright.
All attempts (window.map, DOM lookup, canvas inspection) failed.
In the end, I removed this test and explained the limitation clearly in my PR comments.
Final Result — Simplified and Efficient
| Metric | Before | After | Improvement |
|---|---|---|---|
| Test cases | 7 | 3 | −57% |
| Page loads | 7 | 1 | −86% |
| Lines of code | 190 | 66 | −65% |
| Runtime | ~15s | ~9s | −40% |
The remaining tests now focus purely on core functionality:
- Map initialization and rendering
- Distance calculation accuracy
- Tile loading verification
Key Learnings
🎯 Define Clear E2E Boundaries
- ✅ Test user interactions and functional outcomes
- ❌ Don’t test static HTML or styling
⚡ Optimize for Efficiency
- Use shared pages or contexts
- Add listeners before page load
- Remove redundant tests
📏 Prefer Precision
- Use exact expected values instead of ranges
🧩 Handle Technical Limits Gracefully
- Try multiple approaches
- Avoid modifying production code unnecessarily
- Communicate clearly when a limitation exists
💬 Communicate Like a Collaborator
A good PR response acknowledges issues, explains reasoning, and proposes alternatives —
“Happy to discuss alternative approaches.”
goes a long way in maintaining a positive contributor-maintainer relationship.
Conclusion
This contribution taught me that:
- Quality over quantity — meaningful tests matter more than many tests
- Performance is strategic — fewer reloads, faster runs
- Communication is key — technical skill and collaboration go hand in hand
Open-source work isn’t just about code — it’s about learning to cooperate, explain trade-offs, and evolve with feedback.
Top comments (0)