BDD (Behavior Driven Development) è utilizzato nei giochi?

Ho letto su BDD - Behavior Driven Development da un po 'di tempo e trovo davvero facile e utile convertire le funzionalità in codice. Gli utenti BDD spesso lo chiamano TDD fatto bene.

BDD è uno strumento per la progettazione di software, dall'esterno all'interno, dal valore di bussiness (o valore di gioco) al codice.

Dan North presenta BDD

Conosci altre risorse su BDD e giochi diversi da questo ?

Probabilmente è sicuro affermare che BDD, come TDD, o (inserire qui un paradigma di parole d'ordine di sviluppo alla moda) è usato da alcuni sviluppatori di giochi da qualche parte, ma probabilmente non sanno di essere o non sarebbero necessariamente in grado di identificare cosa significa effettivamente BDD . La domanda è davvero quanto la usano e quanto devono usarla perché ciò contenga per te?

Ad esempio, dove lavoro, tutti i nomi dei nostri test unitari sono "frasi" come suggerisce Dan North in quell'articolo che hai collegato. Questo da solo non è sufficiente per dire che usiamo BDD, ovviamente, ma forse è quello che ti interessa davvero?

L'attenzione, a mio avviso, non dovrebbe essere su quale parola d'ordine si applica in uno studio, ma piuttosto su quali tecniche di produttività e processo di sviluppo impieghi nel complesso. Trovo che i team più produttivi stiano mescolando e abbinando tecniche provenienti da una varietà di "paradigmi di parole d'ordine" piuttosto che impegnarsi, dogmaticamente, in ogni po 'di rigida dottrina che alcuni studi su Internet dicono che comprende un particolare paradigma di parole d'ordine.

Lo vedo molto spesso con la tendenza Agile: i team che si identificano come "facendo Agile" tendono ad essere più inflessibili (ironicamente) del processo rispetto ai team che organicamente incorporano i frammenti di Agile che hanno senso per loro. Le ex squadre finiscono quasi sempre per essere meno produttive, secondo la mia esperienza.

Un team di sviluppo è composto da umani, che non sono ingranaggi intercambiabili in una macchina. Operano unicamente come individui e come la combinazione unica di se stessi. La strada per uno sviluppo efficace non è di piegare i tuoi umani nello stampo {BDD, Agile, What'sIsNext}, ma di rivalutare costantemente il modo in cui il team sta progredendo e sostenere le carenze nel processo, sostituendo i problemi tecnici rotti e rafforzando le cose che sono Lavorando. In breve, concentrarsi sulla spedizione di un titolo e non su "essere Agili (o qualsiasi altra cosa)".

È? Può essere. La mia opinione sarebbe che sarebbe una soluzione molto scarsa per il software di intrattenimento in generale, anche se potrebbe funzionare bene per le librerie di basso livello.

EDIT: Ecco alcune giustificazioni per la mia opinione.

Wikipedia definisce BDD una tecnica che "incoraggia la collaborazione tra sviluppatori, QA e partecipanti non tecnici o aziendali a un progetto software". Sembra già una cattiva idea perché i giochi differiscono dalla maggior parte dei software in quanto non sono progettati come strumenti per soddisfare un'esigenza specifica di un "partecipante non tecnico o aziendale", ma sono opere coese ampiamente progettate per intrattenere. C'è un'enfasi sul "comportamento software desiderato", ma i giochi raramente hanno un "comportamento software desiderato", tranne a livello tecnico. C'è sicuramente il merito di controllare quella parte del codice, ma non con l'utente finale, perché non lo vedranno mai.

Ma supponiamo che tu voglia buttare via quella roba degli stakeholder umani e usare semplicemente BDD per far rispettare i contratti tra diversi moduli di codice, che per quanto posso vedere non differisce molto dal normale sviluppo guidato dai test, che considero scarsamente- adatto ai giochi, per il seguente motivo.

I test sono utili per verificare che eventi discreti si siano verificati quando previsto. Questo funziona bene nella programmazione guidata dagli eventi, ad es. la maggior parte del mondo del software, in cui viene eseguita un'azione, viene generato un po 'di output e quindi si verifica che l'azione e il risultato corrispondano. Tuttavia, il software di gioco è in genere una simulazione, in cui un'azione non ha un risultato discreto ma un cambiamento continuo nello stato mondiale. Se il mio giocatore nascosto fa rumore, potrei voler controllare che l'IA mi dia la caccia. Quindi, posso creare un test per assicurarmi che l'IA sia nello stato di "caccia" dopo che è stato creato un rumore, ed è fantastico. Ma come faccio a sapere se la caccia funziona anche? Non puoi verificarlo all'istante: puoi osservarlo solo con il passare del tempo.

Inoltre, un approccio test-first può creare un falso senso di sicurezza e indurre le persone a credere che il codice sia migliore di quanto non sia in realtà.

def check_dice_roll_in_range():
    d = new Dice()
    assert(d.roll() between 1 and 6)

class Dice:
    def roll():
        return 4

Poiché un risultato del test può dare un falso positivo, non è mai possibile sfuggire alla necessità di base di controllare il codice stesso. Ma se il codice stesso viene verificato adeguatamente, il test assume un'importanza secondaria. Questo è il motivo per cui, a mio avviso, i test vengono utilizzati al meglio dopo l'evento, per testare correzioni di errori.

Non direi che non c'è mai alcun vantaggio nel testare che, quando gli oggetti X e Y lavorano insieme, il risultato ottenuto è come previsto. Il problema è se stai usando il modo più efficace per verificarlo. I metodi potrebbero includere la verifica formale, una revisione del codice, i metodi test-first, i metodi last-test, i test tradizionali sulla scatola nera del QA o semplicemente usando il codice come previsto e osservando i risultati. Le ultime due opzioni sono sorprendentemente efficaci per la maggior parte del tempo, perché nonostante sembri che manchino di rigore, la maggior parte dei bug si trova nel corso dell'uso tipico e la comprensione di un bug nel suo contesto naturale a volte può essere più semplice della comprensione in un test artificiale imbracatura. In cima a questo,

Quindi, in sintesi, penso che lo sviluppo basato sui test non sia necessariamente un'ottima scelta per il software, che i test da soli non sono mai sufficienti per garantire la qualità del software (e quindi il tempo impiegato per scriverli deve essere confrontato con usi alternativi di quel tempo di sviluppo), che i giochi sono particolarmente scarsi per i casi di test automatizzati e che i giochi sono particolarmente scarsi per i metodi di sviluppo che mirano a enfatizzare il "valore commerciale" e i "test di accettazione".

(Spero che sia una risposta migliore, anche se non sei d'accordo con i miei punti.)

Penso che BDD sia appropriato in ogni ambiente. Come altri hanno già detto che stai sviluppando software e, di conseguenza, dovresti testarlo. Mi piace bdd per alcune semantiche casuali menzionate come nomi di test come frasi. Mi piace anche raggruppare alcuni test insieme pur essendo in grado di testare 1 classe.

Per combattere altri messaggi qui vorrei sottolineare che su un progetto più ampio è MOLTO più difficile refactificare il codice senza test. Se rifletti qualche codice stai volando alla cieca se tutto esploderà in un tripudio di gloria o no. I test ti aiutano a prendere le cose in anticipo. Quindi scrivi il tuo test, fallisci, codice quanto basta per passare e continuare. Quando refatti dovresti fare la stessa cosa, ma invece di scrivere rivedi il test. Nella maggior parte dei casi esegui il test fallirà, cambierai ciò che pensi dovrebbe cambiare e ANCORA fallisce. A quel punto ti rendi conto che qualche altra parte di codice si basa su questa funzione / metodo in un modo completamente diverso. È quindi possibile correggere il test e il codice risultante. Senza quel tipo di copertura del codice ti imbatteresti per giorni cercando di trovare dove sono rotte le cose,

Leggi i "Contratti" nel libro di Prammmatic Progammer. Il test ti aiuta a ottenere contratti di codice. Questo codice fa X e nient'altro che X e non si aspettano che faccia qualcosa su Y o provi ad adattarlo per fare Z. Assicura la pulizia del codice e si aspetta che tutti non siano pazzi e confondono la base di codice.

Ci sono più motivi per BDD. Il principale per me è che farei lo stesso numero di test per convalidare i miei presupposti, in modo da poterlo formalizzare.

Sul punto di "come" dipende davvero dal tuo ambiente. Sto scrivendo un gioco Java e sto usando robolectric. Dovresti sempre tentare di "aspettarti" qualcosa. Ho sentito che spie / beffe / tronconi non sono così utili poiché devi avere un equivalente dall'altra parte, ma a volte non hai scelta, specialmente con le API. Puoi supporre che l'altro lato dell'API non sia terribile e di solito è il tuo codice che fa schifo.

Se ad esempio stai testando il movimento. Bene, ci si aspetta quando si preme "Su" che l'utente avanza di qualche misura.

Se per esempio stai testando il rendering grafico ... beh, non testarlo troppo perché lo stai davvero facendo? Un buon framework di test potrebbe gestire questa parte per te. La riflessione non è super banale, direi per questo genere di cose. Potrebbe essere necessario controllare i buffer, ecc. Mi limiterei a controllare cosa stai effettivamente facendo. Il personaggio è qui, ora è lì dopo qualche azione.

Dovresti avere un sacco di piccole funzioni / test piccoli e insieme riassumeranno qualcosa di utile.

Sento che c'è un'idea sbagliata su cosa sia BDD. BDD non è una tecnica o un processo di TEST. BDD è un modello e un processo di sviluppo. Va ben oltre i test e va ben oltre la programmazione.

In quanto tale, non conosco nessun grande studio AAA che lavora con questo modello (ho amici che lavorano per alcuni di loro in tutto il mondo come programmatori). Come ha sottolineato qualcun altro, è possibile che alcuni project manager o team da qualche parte incorporino alcune delle pratiche che BDD comprende, ma non conosco nessuno studio che applica puro BDD (dalla definizione del valore aziendale, alla specifica dall'esempio, alla scrittura file di funzionalità, per convalidarli con gli azionisti, per automatizzare i file di funzionalità come test).