in een Rails-apps, hoe Cucumber .feature-bestanden te organiseren?

toen ik aan dit project kwam, waren er komkommertests in "features/enhanced", die met JavaScript en een paar in "features/plain" draaiden, waarvoor geen JS nodig was. met de latere ontwikkeling van per-scenario @ JavaScript is dit niet logisch. en aangezien het aantal functiesbestanden dat we hebben groeit en groeit, zou het geweldig zijn als dit netjes zou blijven.

dus, in de beste praktijk land:

1) hoe lang moeten .feature bestanden zijn? ik probeer elke smal en specifiek te houden met 1 of 2 "Scenario's".

2) in welke map/bestandsstructuur moet men ze bewaren?   2a) hoe zou een groep vergelijkbare functies kunnen hebben?

 0
toegevoegd
Bekeken: 27
de bron

2 antwoord

1) Als je ze een paar maanden hebt gebruikt, zul je snel ontdekken wat voor jou het beste werkt. Mijn advies is dat je ze klein moet maken. We hebben onze eerdere functies vaak opgedeeld in kleinere stukjes, maar zijn er nooit in geslaagd om ze te combineren. Het is handig voor het gebruik van achtergronden etc ...

2) We hadden een groot probleem hiermee en brachten het eeuwenlang op de een of andere manier. Uiteindelijk schoten we neer om ze te groeperen op basis van de diensten die ons bedrijf levert. bijv. betalingen, klantregistratie, voorraadbeheer

Ongemakkelijk voldoen kenmerken niet altijd aan een hiërarchische boomstructuur van de wereld, dus maak liberaal gebruik van tagging en uw primaire groepering van functies is minder belangrijk.

Heb je yard geprobeerd? Er is een voorbeeld hier We hebben het zojuist in onze CI gebouwd, hiermee kunt u sets met scenario's maken op basis van tags, je kunt vakbonden, kruispunten etc. doen ... zeker de moeite waard :)

2
toegevoegd
de bron
geweldig, bedankt. ik ben altijd in de verleiding om vast te houden aan een of andere op een controller gebaseerde organisatie. ik ben het ermee eens dat dit met "eigenschappen" opsplitst.
toegevoegd de auteur whatbird, de bron

Ik zou de JavaScript- en niet-JavaScript-versies van een scenario bij elkaar houden, omdat ze erg op elkaar zouden moeten lijken.

Iets meer dan 8 scenario's in een bestand met functies is waarschijnlijk te veel.

Een nuttige benadering is om een ​​map te hebben die de functies op hoog niveau weergeeft (soms epics of thema's noemen) en aparte feature-bestanden in die mappen voor de verschillende aspecten van het gedrag.

U kunt bijvoorbeeld een functie "Medewerkersdirectory" hebben met afzonderlijke functiebestanden die scenario's bevat voor een foto, kantoorlocatie, functietitel, enz.

Afhankelijk van de grootte en complexiteit van uw app, kunt u deze mappen in andere mappen groeperen.

(Merk op dat geen van de bovenstaande punten specifiek is voor Rails-apps).

1
toegevoegd
de bron
bedankt, ja, de scheiding van js/non-js vloeide voort uit een vroege implementatie, ik zal het graag gooien. meer mappen!
toegevoegd de auteur whatbird, de bron