Refactoring of cucumber and playwright Acceptance tests with Github Copilot | R-Bloggers

From my experience, LLMS are much better at writing JavaScript code than in writing R code at the moment.

I wanted to check how well Copilot is doing with refacting existing test code for playwright and cucumber.

Refactory of existing test code

Before I had refactoring, I had a single step definition file that contained all Step implementations:

• interactions with forms,
• Navigation steps,
• Output verifications,
• and hook

Mixed together.

Placing all step definitions in one file when you are just starting to write tests is fine, but as more steps are added, it becomes log.

Ask with documentation context

I have submitted Copilot with the following instruction to refact my step files based on the best practices described in the articles of which is referred to about step -by -step organization And anti-pattern of the cucumber documentation.

It proposes to organize step definitions by Domain concepts To prevent duplication and to support and re -use maintenance for functions. Let’s see how Copilot deals with this.

I want to refactor my cucumber steps implementations to follow best practices.

Read those articles:
#fetch https://cucumber.io/docs/gherkin/step-organization
#fetch https://cucumber.io/docs/guides/anti-patterns
and apply what is suggested.

Before doing the changes, explain the plan.

The reaction was as follows:

I'll help you refactor your cucumber steps implementation to align with industry standards. Let me first gather information from the articles you've shared so I can create a comprehensive plan. Based on the Cucumber documentation, here's my plan to refactor your steps implementation to align with industry standards:

## Refactoring Plan for Cucumber Steps

### 1. Reorganize Step Files by Domain Concept

Currently, all your step definitions are in a single `steps.step.mjs` file. While this works for smaller projects, as your project grows, it's better to organize steps by domain concept.

**Plan**:
- Create separate step files for different domains in your application
- Group related step definitions together based on functionality
- Potential files could include:
  - `navigation.steps.mjs` - For navigation steps
  - `form.steps.mjs` - For form interactions
  - `chat.steps.mjs` - For chat-related interactions
  - `configuration.steps.mjs` - For configuration-related steps
  - `file-operations.steps.mjs` - For file upload/download operations

### 2. Create Helper Methods for Reusable Code

The current implementation has several step definitions with similar code patterns. We should extract common functionality into helper methods.

**Plan**:
- Create a `helpers/` directory with utility functions
- Extract common patterns for:
  - File operations (upload/download)
  - Form interactions
  - Waiting for UI elements
  - JSON assertions and handling

### 3. Make Steps More Atomic and Reusable

Some of your steps are doing multiple things at once, which makes them less reusable.

**Plan**:
- Split conjunction steps to make them more atomic
- Make step definitions more generalized to increase reusability
- Parameterize steps to handle more variations without duplicating code

### 4. Improved World Context and State Management

Currently, you're using a global `state` object. A more structured approach would be beneficial.

**Plan**:
- Use Cucumber's World object for state management
- Create custom World extensions for different domains
- Implement proper scoping of state variables

### 5. Better Error Handling and Reporting

Enhance error handling to provide more meaningful feedback when tests fail.

**Plan**:
- Add better error messages and context when assertions fail
- Implement custom error handling where needed

## Implementation Steps

Let me start implementing these changes:

1. First, I'll create a directory structure for our step definitions
2. Create helper methods for common functionality
3. Refactor the existing steps to use the new structure
4. Apply proper state management patterns

Let me know if you'd like me to proceed with these changes or if you want to modify the plan before I begin implementation.

Result

Was it a good distribution of files?

Copilot did indeed split the file into several. But is it good?

It has made the following files:

• navigation.steps.mjs – For navigation steps
• form.steps.mjs – For form interactions
• chat.steps.mjs -For chat-related interactions
• configuration.steps.mjs -Fon steps with configuration-related steps
• file-operations.steps.mjs – For operations for uploading/downloading files

Is it a split by one domain? I’m not sure. It seems more like a split through function.

But in my case it is still a good split, because it organizes the test code better than before. I can work with it and see if other domains arise in the future. It is absolutely not a tight link between functions and step definitions, which is a step in the right direction.

Improvement of helper methods

It created one /helpers Directory with utility -Functions for:

• File arrangements (upload/download)
• Form interactions
• Waiting for onion elements
• Json -Verwingen and Handling

It helped me to prevent code duplication and made the step definitions cleaner. Copilot was not explicitly asked about it, but it was a good addition.

Copilot taught me about cucumber functions that I didn’t know

While Copilot refacted the code, it introduced me to a cucumber function that I was not aware of – the World object.

It appears that this is a more convenient approach to manage the status in cucumber tests. You do not have to implement your own state management logic. Instead, you can use the built -in world object to save the status and open the steps.

Copilot may know more about the library you use than you, so it’s worth paying attention to the suggestions.

Conclusions

Although the refactoring was not perfect, it was a considerable improvement compared to the original code.

Explicitly telling a cop to follow practices in a certain article can help follow specific patterns that you want to see in the code. The biggest victory was that I learned a number of new cucumber functions that I was previously not aware of.

I intend to test how good Copilot writes all over again when writing theater writers and cucumber test code, perhaps it is good enough to quickly cover fast, shiny apps with acceptance tests.

🧪 Check this manual for testing legacy shiny apps.

Related