Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
Gather requirements of the entire app and organize in a folder
Place individual scenarios in folders. These scenarios will serve as the base units for building out e2e tests and logging - ensuring that the new app will match the functionality of the current app.
Add console logs to each function that will need to be rewritten. Functions need to be rewritten if they are dependent on framework-specific code or are components.
Make a list of all functions and components in the code base.
Based on each scenario - write an e2e test in Playwright that captures screenshots at each GHERKIN stage of the scenario.
Capture all console logs in their own log files as each test is run. This will verify the flow of the components/functions being tested that need to be rewritten.
Prompts:
Analyze the #codebase. List the features that would be strong candidates for E2E tests. Take your time to review thoroughly.
For each major feature area, specify requirements.
Where each requirement will be written with GHERKIN like format.
Please build out each requirement/scenario individually. Many files are ok.
Example output format:
/rewrite/{area}/{requirement}/{scenario}/scenario.md
Only one scenario should be in each scenario.md file. Break out related scenarios into separate folders.
Example output scenario:
rewrite/authentication/user_registration/registration_with_existing_email/scenario.md
Example scenario.md content:
Given an account already exists with my email
When I try to register with the same email
Then I see an error message indicating the email is already in use
You are a software developer adding logging to a project, so other developers can see what functions are called, with what arguments, how often, and by which functions.
Terms:
{path-to-module}: file path of the current piece of code relative to the root of the project.
{name-of-code-unit}: name of the function.
Prompt the user for a folder name. Find every JavaScript file inside that folder and its sub-folders and process them.
Make a list of every code unit. A code unit is:
A component
A non-clean function
Save these lists in a new folder located in the app-requirements/code-units.
When processing a file, perform three actions. Do not skip any action.
1.Identify "non-clean" JS functions used by this project. A "clean" function is a function that would make sense to keep exactly how it was if this project was written to any other framework but the language kept in place.
2.add console.log statements to the top of each non-clean function. The console.log call should be in the format {path-to-module}:{class-name}:{name-of-code-unit} {arguments}. If an argument is an object or array, display the stringified version. If the argument is a function, display the name of the function.
3 add console.log statements right above any function call in the format {path-to-module}:{name-of-code-unit} calling {function-name} {arguments}. Ignore calls to:
require()
stopPropagation().
import
Only add console.log statements. Do not change any other part of the code. Do not add any other code.
Configure the app-requirements folder to be a standalone environment that Playwright can be run in.
Do not write any tests, or make any changes outside of this folder.
The app runs in a docker container, and is accessed by port 5001
Create a file inside app-requirements that has a function that registers two users as a global set up when tests are ran.
The users should be registered before any tests are run, and if the users already exist, just exist and continue with the tests.
The first user registered will automatically be the admin, and the second will be a regular user.
The users should be able to be accessed from a reusable function.
In the app-requirements/authentication/user_login/successful_login folder, there is a scenario.md.
Based on the contents of that file, create a Playwright test next to the scenario.md file and then run the test to confirm it passes.
If it does not pass, fix it.
I found that having Claude Code test each test after writing it before moving on allowed it to create passing tests faster. Instead of writing them in bulk and then running at the end.
Ultimately, both Copilot and Claude Code struggle here to write passing tests/tests that actually test the functionality.
Do the same for the rest of the scenario.md files, and make sure to place the test files next to their respective scenario.md files.
After each test is created, run it to ensure it passes.