SHIPPED

Test Automation Code Generator

An internship tool at Brightest that pulls test methods out of a team's existing code on GitHub and generates ready-to-use test code in their own framework, aimed at testers with less coding background.

Metadata2025
Role
Intern, built with a fellow student
Context
Internship at Brightest, Kontich
Timeframe
Feb to May 2025
Stack
Next.js, React, TypeScript, MongoDB, MSAL, C# parsing

// Problem

Brightest does test automation, and writing test scripts was hard for people there with less of a coding background. Tools like Playwright and Selenium can generate code by recording, but nothing pulled the methods the team already kept in their Page Object Model files on GitHub to make code that fit Brightest's own test framework.

// What I built

After looking into how to read methods out of JavaScript, TypeScript and C# files and getting a proof of concept working (with a fellow student I knew from the Atlas Copco project), we built a Next.js app with MongoDB for storing the setup and Microsoft sign-in for login through the Brightest environment. The flow: sign in with a Microsoft account, point the tool at a GitHub repo with a personal access token, pick the code files, compose test cases from the methods it found, and generate test code you can paste straight into a test environment. State runs through the React Context API, with services and Next.js API routes on the backend.

// Some decisions I made and why

  1. 01I pulled methods from their existing code instead of recording clicks

    Playwright and Selenium already make test code by recording what you do. Instead, the tool reads the methods the team already keeps in their Page Object Model files and builds code that fits Brightest's own framework, so testers reuse what they already have instead of throwaway scripts.

  2. 02I wrote a small parser for their code files

    Methods get pulled out of JavaScript, TypeScript and C# files with a parser I wrote, which kept the proof of concept small enough to finish inside the internship. The downside is that reading code this way is simpler than a real parser and needs care around edge cases.

    PomExtractor.ts
    export class PomExtractor {
      static extractMethodsFromTs(fileContent: string): PomMethod[] {
        const methods: PomMethod[] = [];
        const methodRegex = /(?:async\s+)?(\w+)\s*\(([^)]*)\)\s*{/g;
        let match;
    
        while ((match = methodRegex.exec(fileContent)) !== null) {
          const methodName = match[1];
          const paramsString = match[2].trim();
    
          if (methodName === 'constructor' || methodName.startsWith('_')) continue;
    
          const params = paramsString
            ? paramsString.split(',').map(param => {
                const [name, type] = param.trim().split(':').map(p => p.trim());
                return { name, type: type || 'any' };
              })
            : [];
    
          methods.push({ name: methodName, parameters: params, returnType: 'void' });
        }
    
        return methods;
      }
    }
  3. 03I put the login behind their Microsoft accounts

    Sign-in goes through Microsoft Authentication so the tool sits inside Brightest's existing accounts, which was a requirement of working there and meant learning MSAL on the job.

// Outcome and status

Shipped at the end of the internship: testers sign in, point the tool at a repo, and generate framework-ready test code from the methods it found. It was my first time building in a professional setup, which meant getting used to new workflows, checking requirements with the project manager and stakeholders, and designing how the extraction and generation fit together.

// What I'd change next

With more time I would replace the pattern-based parser with a proper one per language, which would handle the edge cases the proof of concept does not.

// Links

Internal Brightest project, so there is no public repo or hosted demo.