Sviluppo guidato dai comportamenti e test unitario in Python [chiuso]

Prova pyspecs . Rendere i test facili da leggere e costantemente in esecuzione durante lo sviluppo sono stati due dei miei principali obiettivi nella creazione di questo progetto.

Codice test:

from pyspecs import given, when, then, and_, the, this

with given.two_operands:
    a = 2
    b = 3

    with when.supplied_to_the_add_function:
        total = a + b

        with then.the_total_should_be_mathmatically_correct:
            the(total).should.equal(5)

        with and_.the_total_should_be_greater_than_either_operand:
            the(total).should.be_greater_than(a)
            the(total).should.be_greater_than(b)

    with when.supplied_to_the_subtract_function:
        difference = b - a

        with then.the_difference_should_be_mathmatically_correct:
            the(difference).should.equal(1)

Uscita console:

# run_pyspecs.py

  | • given two operands 
  |   • when supplied to the add function 
  |     • then the total should be mathmatically correct 
  |     • and the total should be greater than either operand 
  |   • when supplied to the subtract function 
  |     • then the difference should be mathmatically correct 

(ok) 6 passed (6 steps, 1 scenarios in 0.0002 seconds)

Sebbene esistano strutture BDD come la lattuga o il comportamento (che è meglio scegliere con la loro documentazione ed esempi), hai menzionato che hai iniziato senza questo. Quindi la mia risposta sarà più legata a questa situazione.

Il BDD originale è iniziato con fork di JUnit, che, invece di chiedervi di nominare i vostri test con "testSomething", vi chiedeva di chiamarli "shouldDoSomething". È così che dovresti essere concentrato sulle cose.

Quindi sono andato allo stesso modo nel mio progetto. Ho appena iniziato a dare un nome ai test che iniziano con "test_should _..." e provo a dare loro nomi descrittivi. È così che stai ancora facendo BDD, sei ancora concentrato su cosa esattamente dovrebbe fare quel test, ed è facile scrivere qualcosa che convertirà i tuoi nomi di test in frasi normali (se avrai bisogno, ovviamente). Trovo che questo approccio sia un proiettile argentato dal momento che (specialmente nei linguaggi script) non voglio mai perdere tempo con nomi inutili (come il nome del test in caso di quei framework BDD in cima).

Ho lavorato su un framework BDD chiamato Contesti , ispirato a C # Machine.Specifications .

Contesti ti incoraggia a scrivere frasi descrittive user-centric per i tuoi test (che è ciò che riguarda in realtà il BDD) diffondendo i casi di test su un'intera classe. Le fasi arrangiamento / atto / asserzione del test sono messe in singoli metodi corti, ei Contesti capiscono quale metodo è basato sul loro nome.

Un'immagine parla più di mille parole, quindi ecco un esempio tratto dal readme:

import requests

class WhenRequestingAResourceThatDoesNotExist:
    def given_that_we_are_asking_for_a_made_up_resource(self):
        self.uri = "http://www.github.com/itdontexistman"
        self.session = requests.Session()

    def because_we_make_a_request(self):
        self.response = self.session.get(self.uri)

    def the_response_should_have_a_status_code_of_404(self):
        assert self.response.status_code == 404

    def the_response_should_have_an_HTML_content_type(self):
        assert self.response.headers['content-type'] == 'text/html'

    def cleanup_the_session(self):
        self.session.close()

Contesti ha anche una serie di funzioni moderne come test parametrizzati, "assertion-rewriting" (ispirato a py.test) e un framework di plugin.

Ho usato Contesti per testare se stesso, così come su alcuni altri progetti (anche progetti non Python), e ho trovato che produceva test comprensibili e comportamentali a tutti i livelli del triangolo di test (a differenza di unittest che non era progettato per il test di accettazione, o lattuga che non è stato progettato per il test di unità).

Penso che dovresti provare Morelia: link

Passa il tuo elenco di requisiti in 4 punti:

1. È uno strumento BDD basato sul modulo Unittest di Python
2. Test eseguiti sono descrizione testuale
3. Se puoi eseguire automaticamente i Test unitari tradizionali, Morelia può essere eseguito allo stesso modo.
4. Penso che l'elemento di configurazione più comune per github sia Travis-CI che può eseguire test di unità in modo che possa eseguire Morelia.