TDD e in attesa di dipendenze

Sono stato un dev mobile in questa situazione.

Abbiamo fatto entrambe le cose. Il team mobile ha bisogno di dati falsi controllati, quindi non si rompono quando l'interfaccia cambia. Il team API dovrebbe prendere in giro l'interfaccia perché è un test migliore che tutto funzionerà quando rilasceranno.

Ma si riduce a un problema di gestione. In entrambi i casi risolve il problema. Uno di voi deve smetterla di discuterne e digitare del codice.

Nel tuo caso gli sviluppatori mobili sono quelli che aspettano, quindi presumibilmente hanno il tempo di prendere in giro alcuni apis.

Dato che stai chiedendo chi dovrebbe fare il mockup nello sviluppo: team del cliente o team del server?

risposta breve "entrambi insieme"

Nei miei progetti mi piace preoccuparmi così

• definire un API tra client e server (ovvero un'interfaccia java o c # con nome del metodo, parametri di input e parametri di output o una firma di riposo)
• un formato di testo leggibile per i dati di dati non standard che possono essere facilmente implementati nel codice client e server (ad esempio xml, json)
• un prototipo di dati di interfaccia utente: quando il client chiama methodA dell'interfaccia B con questi parametri, il servizio restituirà questo xml.

dato che gli sviluppatori client e server fanno questo insieme, facciamo in modo che entrambe le esigenze siano soddisfatte

il risultato è il 90% del codice mockup.

il lato clinet inizia ad implementare la propria simulazione implementando l'interfaccia java / c # che legge il prototipo dati xml da un file su disco. Quindi continua a scrivere il codice da convertire tra xml e modello di oggetto interno (serializzazione)

il lato server inizia ad implementare il suo servizio come un webservice che legge il prototipo di dati xml da un file su disco. Quindi continua a scrivere il codice da convertire tra xml e modello di oggetto interno ((de) serializzazione)

se sia il client che il server utilizzano la stessa lingua, il codice (de) serializzazione deve essere scritto una sola volta

TDD è una cosa divertente. Capisco che devi aspettare che gli altri team finiscano prima di scrivere i tuoi test, ma non è questo il caso!

Mentre utilizzi TDD, molto probabilmente scriverò molti Test unitari. Questi test non sono intesi per testare un intero sistema, ma piuttosto una piccola parte di esso. Questi test esistono per dimostrare che una funzione funzionerà con i dati forniti, in molte circostanze (ogni circostanza sarebbe un test). In questo modo ti costringerai a simulare / bloccare gli oggetti perché devi controllare cosa entra e chi esce dalle funzioni sotto test.

Per questo motivo non è necessario attendere nessuno per il codice. In realtà, dovresti prendere in giro / stoppare oggetti per produrre dati che ti aspetti di entrare nelle tue funzioni e semplicemente rendere questi banchi simili in funzionalità a ciò che ti aspetti da queste classi.

In primo luogo, se seguirai la mischia, allora non hai team Web Api, iOS e Android: hai solo il tuo team di mischia. Se le squadre esistenti sono troppo grandi per essere tutte parte di una squadra (3-9 massimo per una squadra di mischia), allora sei nel territorio di "mischia", in cui sarai essenzialmente in una mischia di mischia. Esistono diverse metodologie per questo, ma in generale, avrai un team di scrum composto dai proprietari dei prodotti dei tuoi team di mischia più piccoli. Questo team globale scrum avrà il proprio proprietario del prodotto, che essenzialmente possiede tutto. L'arretrato, quindi, filtra dall'alto. Dove il proprietario del prodotto principale mantiene l'intero backlog del prodotto completo e ciascun proprietario del prodotto del team di scrum mantiene l'arretrato per quel particolare team.

In entrambe le impostazioni, il processo è ancora praticamente lo stesso. Ci dovrebbe essere un PBI per il lavoro Web Api e PBI per ogni pezzo di lavoro specifico per piattaforma. Se il Web Api PBI è una dipendenza, i PBI specifici della piattaforma non possono essere elaborati fino a che il PBI non viene eseguito, il che significa che devono attendere lo sprint successivo. Organizzato in questo modo, tutti stanno ancora lavorando attivamente su PBI nel backlog, ma potresti non essere in grado di distribuire particolari funzionalità in un singolo sprint quando hanno preoccupazioni trasversali. Va bene, e la roadmap del tuo prodotto dovrebbe tenere conto di queste situazioni.

@Rhys Johns ha detto bene: in TDD realizzi costantemente piccoli stub per testare le tue funzioni.

MA. Ci sono mozziconi e mozziconi ... Non dovremmo mescolarli o dimenticarli di qualsiasi tipo.

Se ricorderemo che i metodi agili sono stati accettati, vedremo che la versione di avvio di ogni pezzo di SW è di per sé un mozzicone. Quindi, i ragazzi del server dovrebbero iniziare con la creazione di uno stub, che simula solo il server per i client. E i clienti iniziano con la creazione di uno stub, che simula l'interfaccia utente per gli utenti. Nella SECONDA fase eseguiranno la versione che simulerà il lavoro con il server. Successivamente visualizzeranno le informazioni, simulate dal server nell'interfaccia utente. Il passo successivo è che l'utente lavori con lo stub del server.

E su qualsiasi livello usiamo ancora TDD, creando così piccoli stub, testando funzioni separate.