Culture

Check out the story of Lablup

May 29, 2025

Getting your first green square in Backend.AI

  • Seungwon Lee
    Seungwon LeeSoftware Engineer
Backend.AIBuild EngineeringLablup

May 29, 2025

Culture

Getting your first green square in Backend.AI

  • Seungwon Lee
    Seungwon LeeSoftware Engineer
Backend.AIBuild EngineeringLablup

Green Dot Party

Hello! I’m Seungwon Lee from the Lablup front-end chapter. On April 2nd, our team hosted a small event called the “Green Dot Party.” The term “Green Dot” refers to the little green dots that appear next to test cases when they pass successfully after development and testing. Through this event, our goal was to clean up outdated test cases, add new ones, and ultimately bring a whole bunch of green dots into Backend.AI. But before diving into the details of our Green Dot Party, I’d like to briefly explain how product testing works at Lablup.

A green check badge that appears next to a passing test case.

E2E Testing at Lablup

From a developer’s perspective, testing small, isolated units of a function or method is called unit testing. On the other hand, End-to-End (E2E) testing verifies that the entire application works properly from the user's point of view, from start to finish.
Since unit tests alone can’t catch system-wide issues, and E2E tests aren’t detailed enough to catch component-level bugs, we use both types in a complementary way.

CategoryUnit TestE2E (End-to-End) Test
Purpose          Verifies that individual pieces of code or functions work correctlyVerifies that the software works as expected from the user's perspective
Test Scope          Small units of code or isolated functionsEntire system flow including frontend, backend, and database in a real user context
Environment                       Runs in isolation within the codebaseRuns in a real browser environment with full system integration (API, DB, etc.)

Lablup also strives to maintain functional integrity by running both unit tests and E2E (End-to-End) tests during development. Our team works in two-week sprints using Jira, and at the end of each sprint, we release a new build based on the issues merged during that period. As part of the release process, we verify that existing features continue to work correctly, that the UI/UX remains consistent and intuitive, and that backward compatibility with previous backend versions is preserved. While larger companies often have dedicated QA (Quality Assurance) teams, we don’t have a separate QA team at Lablup. Instead, the developers responsible for each feature write unit tests themselves, and before shipping the product, our front-end chapter performs a final review process—called Final Train—which includes running E2E tests.

Maintaining up-to-date E2E scenarios without a dedicated QA team is no easy task. With fast development cycles, tests can quickly become outdated or break when they don’t account for newly added features. On top of that, our front-end chapter is currently migrating from Lit Element-based components to React components while adopting Lablup’s new design system, NEO. This transition has introduced frequent changes—modals becoming full pages, button positions shifting, and so on—making it clear that many of our existing E2E test cases needed to be updated.

However, with our focus on rapidly evolving AI development tasks, refreshing the tests kept getting pushed down the priority list. To address this, we needed a concentrated effort where all team members came together to tackle the problem with a shared goal in a short time. That’s exactly what we did during the Green Dot Party—the entire front-end chapter gathered to identify outdated E2E test cases, share best practices for writing new ones, and take ownership of rewriting and updating them.

Writing E2E Test Cases

To write a solid E2E test, you must clearly understand the user's needs and turn those into accurate, realistic scenarios. At Lablup, we follow Behavior Driven Development (BDD)—a methodology that puts user scenarios at the center, not the test cases themselves.
BDD uses a common language that everyone—devs, testers, and stakeholders—can understand.

We usually express this using Gherkin syntax, which closely resembles natural language and follows a "Given-When-Then" format:

  • Given: The setup or context for the test 
  • When: The user’s action or interaction 
  • Then: The expected outcome or behavior 

For example, here’s a Gherkin-style scenario for one of Backend.AI’s core features—session creation:

  • Given: The user has logged in and clicked “Start” from the side menu 
  • When: The user clicks “Create Session” to create an Interactive session 
  • Then: The user is taken to the session creation page with the Interactive type pre-selected 

Of course, not all scenarios are this tidy. Some may include multiple “When” and “Then” steps, or what starts as a single scenario may need to be split into several smaller ones. During the party, we discussed these nuances and worked together to create consistent, well-scoped test cases.

After writing them, we carefully verified that all tests completed correctly. If a test causes unintended side effects, it could ruin the results of all others. For example, if a session is created during a test, we make sure to clean it up afterward to avoid interference. In Playwright, we handle this with afterEach to remove any sessions created during a test.

As the saying goes, “a beautiful person leaves a beautiful trace.” At Lablup, we believe the same applies to code and tests—beauty lies in clean beginnings and clean endings.

Wrapping Up

During the Green Dot Party, our front-end chapter came together to refresh outdated E2E cases, share scenario-driven testing methods, and validate results. In just three hours, we updated eight test cases and added five new ones. It was a meaningful step toward improving product reliability and keeping our test coverage aligned with the rapidly evolving codebase.

Since we operate in a hybrid and remote-friendly work environment, it's rare to have the whole team in one place—so we value these moments deeply. The day of the Green Dot Party also happened to be the day our front-end lead, Jong-eun Lee, visited Korea from Bali, where he works remotely. For me, it was the first time meeting him in person since my intern days—we had only interacted online until then. So in the end, our Green Dot Party wasn’t just a celebration of green test dots in Visual Studio Code—it was a celebration of team spirit.

Lablup continues to grow rapidly, and we’re always looking for great engineers to join us. We also regularly run internship programs and hire across various roles. We hope to welcome even more teammates at the next Green Dot Party. Until then, I’m off to plant more green dots in VS Code. Thank you for reading—this was Seungwon Lee from Lablup’s front-end chapter!

Lablup
  • sns
  • sns
  • sns
  • sns

© Lablup Inc. All rights reserved.

KR Office: 8F, 577, Seolleung-ro, Gangnam-gu, Seoul, Republic of Korea US Office: 3003 N First st, Suite 221, San Jose, CA 95134
KR Office: 8F, 577, Seolleung-ro, Gangnam-gu, Seoul, Republic of Korea US Office: 3003 N First st, Suite 221, San Jose, CA 95134