Git Workflow per BDD?

Question

Git Workflow per BDD?

#1 da (3 voti)
#2 da (2 voti)

0

Recentemente stavo lavorando con l'approccio Comportamento guidato sviluppo in Rails utilizzando RSpec e Capybara . Tutto sembra a posto e persino nel mio lavoro è possibile accelerare l'intero bridge di pianificazione e sviluppo (definendo il comportamento dell'app rispetto alla documentazione delle specifiche abituali). Ad ogni modo, ecco il mio pensiero: BDD è così bello il motivo per cui non esiste un flusso di lavoro controllo di versione ? Ecco il mio pensiero:

Motivazioni

BDD di solito contiene due elementi di ciascuna funzione:

descritto test
applicazione

Ciò significa che ci sono due entità di ciascuna caratteristica, che dipendono dalla creazione di una funzionalità completa, ma separate fisicamente. Inoltre, la procedura standard (nota anche come cycle ) di costruzione di ogni funzione contiene:

Scrivi test comportamentali
Scrivi implementazione

Sebbene non vi sia alcuna implementazione di questo processo nel controllo della versione, interrogo su Internet perché non ci sono state risposte.

Proposizione

Supponiamo che ci siano tre tipi di rami:

master (o qualche tipo di ramo dev)
desiderio
implementazione (i due verranno descritti in seguito)

desiderio

BDD copre il processo di pianificazione aggiungendo alcuni test di funzionalità particolari prima di scrivere il codice e lasciarli fallire. Perché basta separare questo processo in branca e dire che è auspicabile come dovrebbe funzionare il software. Ad esempio, esiste un ramo wish_A con particolare (basato sul RSpec ) test funzionale . Questo ramo serve solo a sviluppare lo scenario di prova per la funzionalità in una sola volta.

Attuazione

È naturale che ogni desiderio diventi un codice funzionante alla fine. Quindi questo è il modo di implementare il comportamento: ramificando wish_A e implementando un codice funzionante. Con l'ultima parola del ciclo di vita, il ramo di implementazione viene unito in dev o master o in qualsiasi ramo di versione / codename di opther.

Pubblicazioni

Problemi di dipendenza

Ogni ramo wish può dipendere da molti altri desideri. Supponi che:

A_wish e B_wish sono funzionalità di base e indipendenti
AB_wish richiede A_wish e B_wish fuctionallity

Non riesco a capire quali problemi potrebbero verificarsi dopo la derivazione da uno di A o B e unendone un altro. L'implementazione di tali desideri dovrebbe essere simile - con alcuni conflitti o altri problemi di natura tecnica del codice.

Domanda

Non riesco a trovare perché questo non è implementato da un approccio di sviluppo software o perché non funzionerà con BDD . Ci sono motivi particolari per non fare un qualche tipo di approccio generico?

git bdd software

posta Dawid Pura 11.05.2015 - 17:17

fonte

2 risposte

2

Onestamente, questo non suona come qualcosa a cui il tuo VCS dovrebbe interessare. Il tuo VCS dovrebbe preoccuparsi solo della memorizzazione, delle revisioni e della fusione delle modifiche al codice sorgente. L'idea di una lista dei desideri di funzionalità non si adatta a nessuna di quelle cose.

Una wishlist di funzionalità è il dominio di un backlog del prodotto (o qualcosa di simile). Le parti interessate possono depositare nuovi articoli per la lista dei desideri, che sono a loro volta arricchiti dal proprietario del prodotto. Parte di questo aspetto potrebbe essere la scrittura (e la negoziazione con gli sviluppatori) del testo per le specifiche BDD.

Quando un elemento della wishlist è pronto per essere lavorato, gli sviluppatori possono prendere qualsiasi flusso di lavoro a loro piace per implementarlo. Quando c'è un codice da memorizzare e revisionare, il tuo VCS entra in gioco.

risposta data 11.05.2015 - 17:26

fonte

Leggi altre domande sui tag git bdd software

Convalida del server sacrificio in termini di prestazioni con convalida Rich Client? Come rilasciare il software in bundle con licenze diverse?

score 3 · Accepted Answer

In generale, un progetto software è una raccolta di codice, dati e test. In genere questi dovrebbero tutti vivere nello stesso repository. Usare BDD o TDD significa semplicemente fare il check-in (o almeno sviluppare) i test prima di sviluppare il tuo codice. Non deve essere più complicato di così.

Quindi, il motivo per cui non è stato creato alcun flusso di lavoro specializzato è perché non è richiesto alcun flusso di lavoro specializzato. Crei un ramo per la nuova funzione, crei alcuni test e li controlli in quel ramo, quindi scrivi il codice e lo controlli nello stesso ramo.