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.
- 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
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.
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.tsexport 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; } }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.