Refactorizarea testelor de acceptare a castravetei și a dramaturgului cu Copilot Github

Din experiența mea, LLM -urile sunt mult mai bune la scrierea codului JavaScript decât la scrierea codului R în acest moment.

Am vrut să verific cât de bine face Copilot cu refactorizarea codului de testare a dramaturgului și a castraveților existenți.

Refactorizarea codului de testare existent

Înainte de refactorizare, am avut un fișier de definiție cu un singur pas care conținea toate implementările STEP:

• interacțiuni cu formularele,
• Pași de navigație,
• Verificări de ieșire,
• și cârlige

amestecat împreună.

Punerea tuturor definițiilor de pas într -un singur fișier atunci când începeți să scrieți teste este în regulă, dar pe măsură ce se adaugă mai mulți pași, acesta devine nepotrivit.

Cereți cu contextul documentației

Am solicitat Copilot cu următoarea instrucțiune pentru a-mi refacta fișierele de pas în funcție de cele mai bune practici prezentate în articolele referite despre organizarea treptei și anti-modele din documentația de castraveți.

Sugerează organizarea definițiilor pasului de către Concepte de domeniu pentru a evita duplicarea și a susține o întreținere mai ușoară și reutilizarea funcțiilor. Să vedem cum se ocupă Copilot acest lucru.

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.

Răspunsul a fost următorul:

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.

Rezultate

A fost o despărțire bună de fișiere?

Copilot a împărțit într -adevăr fișierul în mai multe. Dar este bine?

A creat următoarele fișiere:

• navigation.steps.mjs – Pentru pași de navigare
• form.steps.mjs – Pentru interacțiuni de formă
• chat.steps.mjs -Pentru interacțiuni legate de chat
• configuration.steps.mjs -Pentru pași legați de configurare
• file-operations.steps.mjs – Pentru operațiuni de încărcare/descărcare a fișierelor

Este o despărțire de un domeniu? Nu sunt sigur. Pare mai mult ca o despărțire de funcționalitate.

Dar, în cazul meu, este încă o despărțire bună, deoarece organizează codul de testare mai bine decât înainte. Pot să lucrez cu ea și să văd dacă apar alte domenii în viitor. Cu siguranță nu este un cuplaj strâns între caracteristici și definițiile pasului, care este un pas în direcția corectă.

Îmbunătățirea metodelor de ajutor

A creat un /helpers Director cu funcții de utilitate pentru:

• Operațiuni de fișiere (încărcare/descărcare)
• Interacțiuni de formă
• În așteptarea elementelor UI
• Afirmații și manipulare JSON

M -a ajutat să evit duplicarea codului și am făcut definițiile pasului mai curat. Copilot nu a fost întrebat despre asta în mod explicit, dar a fost un plus bun.

Copilot m -a învățat despre caracteristicile de castravete pe care nu le știam

Pe măsură ce Copilot a refactat codul, m -a prezentat la o caracteristică de castraveți de care nu am fost conștient – obiectul mondial.

Se pare că aceasta este o abordare mai convenabilă pentru gestionarea stării în testele de castraveți. Nu trebuie să implementați propria logică de management de stat. În schimb, puteți utiliza obiectul World încorporat pentru a stoca și accesa statul pe pași.

Este posibil ca Copilot să știe mai multe despre biblioteca pe care o utilizați decât o faceți, așa că merită să fiți atenți la sugestiile sale.

Concluzii

În timp ce refactorizarea nu a fost perfectă, a fost o îmbunătățire a codului inițial.

A spune unui agent în mod explicit să urmeze practicile într -un articol dat îl poate ajuta să -l solicite să urmeze modele specifice pe care doriți să le vedeți în cod. Cea mai mare victorie a fost că am învățat câteva caracteristici noi de castraveți de care nu mai eram conștient.

Planific să testez cât de bine face Copilot în scrierea de la zero a dramaturgului și a castraveților, poate este suficient de bun pentru a acoperi rapid aplicațiile strălucitoare moștenite cu teste de acceptare.

🧪 Verificați acest ghid privind testarea aplicațiilor strălucitoare.