Integrazione continua e modifica dei test di automazione dell'interfaccia utente esistenti

3

Il nostro team sta attualmente affrontando una situazione in cui stiamo modificando una funzionalità presente nel prodotto oggi. Questa funzione ha i test di automazione del selenio associati.

Stiamo eseguendo una revisione abbastanza importante del sistema, inclusa la sua interfaccia utente. Ci aspettiamo che questo lavoro prenda parecchi sprint. Durante questo periodo, altri team potrebbero svolgere attività che potrebbero influire sulla funzionalità così com'è oggi. Per questo motivo, vogliamo che i test di automazione esistenti per la funzione rimangano intatti in modo che possano rilevare i problemi.

Naturalmente, avremo bisogno di scrivere l'automazione per la funzione, come sarà dopo che saranno state apportate le modifiche. Il modo più efficiente per farlo in una prospettiva Dev / QA sarebbe modificare i casi di test esistenti in un ramo separato (test localmente) e quindi unire tali modifiche quando la funzione è pronta. In questo modo l'automazione esistente continua a funzionare e non è necessario eseguire ulteriori lavori duplicando ogni test.

Tuttavia, questo ramo separato non si adatta bene ai principi dell'integrazione continua (a cui la nostra organizzazione piace aderire). La nostra unica opzione conforme allo standard CI è quella di fare un ulteriore extra di duplicazione dei test per la modifica?

    
posta Robert Winslow Dalpe 10.09.2013 - 19:22
fonte

1 risposta

2

Vorrei provare a vederlo da questo punto di vista:

  • svilupperai un ramo parallelo per un intervallo di tempo definito (che è ovviamente contrario al modello di CI "standard")

  • questo causerà anche uno sviluppo parallelo dei tuoi test - li diramerai di conseguenza (e li unirai di nuovo nel trunk quando unirai il codice sorgente principale).

  • applica quel ramo anche al tuo ambiente CI - ad esempio, se hai build e test automatici su un server, lascia che il tuo server costruisca e test entrambi , il trunk e il ramo, purché esista il ramo

  • puoi ancora applicare tecniche di integrazione continua al tuo trunk e al tuo ramo separatamente

  • per ridurre al minimo lo sforzo di fusione in un secondo momento, dovresti provare a unire tutte le modifiche nel tronco nel ramo di sviluppo il più spesso possibile, una volta al giorno sarebbe meglio. Questo potrebbe non essere semplice nell'area in cui l'interfaccia utente del ramo dev differisce dal trunk, quindi cerca di limitare al minimo le modifiche all'interfaccia utente del trunk in quell'area.

Come puoi vedere, quando lasci il percorso "CI" e fai una branch e fusione a lungo termine, potresti doverlo fare completamente, per tutto il tuo codice sorgente compresi i test e l'ambiente CI , causando ulteriori sforzi amministrativi. Ma a volte l'IC puro non è solo il modello di sviluppo di cui hai bisogno e potrebbe valerne la pena.

EDIT: in alternativa, puoi provare a evitare la ramificazione all'interno del tuo VCS e a risolvere il tuo problema con un attivatore . È possibile progettare l'interruttore in modo tale da poter passare dalla vecchia alla nuova interfaccia utente in fase di runtime. Questo può essere usato all'interno dei test del selenio: modifica i test in modo che i vecchi test vengano eseguiti solo rispetto alla vecchia interfaccia utente (funzionalità disabilitata) e i test adattati alla nuova interfaccia utente solo contro la nuova interfaccia utente (funzione attivata).

    
risposta data 11.09.2013 - 08:40
fonte