Come testare le regole aziendali?

Question

Ho bisogno di un test unitario per assicurarmi di accumulare correttamente le ore di ferie. Ma le ore di ferie si accumulano secondo una regola aziendale, se la regola cambia, il test unitario si interrompe

È accettabile? Dovrei esporre la regola attraverso un metodo e quindi chiamare quel metodo sia dal mio codice che dal mio test per assicurarmi che il test unitario non sia così fragile?

La mia domanda è: qual è il modo giusto per testare le regole aziendali che possono cambiare?

Answer 1

I test devono garantire che il codice rispetti correttamente la regola aziendale. Pertanto, non scriverei test che aggirino le regole aziendali o non si basino sul codice delle regole aziendali stesso. Piuttosto, quando la regola aziendale cambia, per prima cosa cambierei il test per riflettere la nuova regola aziendale, quindi quando il mio codice non supera più il test, vai e correggo il codice in modo che superi il test.

Quello che non vuoi che accada è scrivere il tuo test in modo che quando cambi la modalità di applicazione della stessa regola aziendale, il test si interrompa. È più facile a dirsi che a farsi, ma essenzialmente ciò che si desidera testare è il minimo richiesto per implementare la regola senza dettare troppo strettamente come viene implementato il codice. Se il risultato della regola è diverso, tuttavia, dovresti prima cambiare il test, quindi il codice per abbinarlo.

Inoltre, non si desidera che il test sia accoppiato a dati specifici. Di 'quando fai un calcolo delle tasse, il tuo test non dovrebbe essere scritto per supporre che la classe sotto test usi il 5% come imposta. Invece, è necessario scrivere il test in modo che fornisca la percentuale fiscale e quindi verificare che il calcolo sia eseguito correttamente. Presumibilmente, avrai un intervallo di valori da testare per assicurarti che anche i valori fuori intervallo vengano catturati. Un risultato di ciò è che avrai un design migliore in quanto ti aiuterà a evitare valori codificati e a rendere il tuo codice di produzione più flessibile alle modifiche dei dati.

Answer 2

Ho un'impostazione simile, tuttavia le mie regole aziendali sono compilate ma hanno opzioni configurabili (le tue potrebbero essere diverse). Quando una regola aziendale cambia un modo fondamentale in cui opera, i miei test unitari si interrompono. Questo è effettivamente previsto - e buono! Significa che posso isolare eventuali increspature inattese nel mio sistema e aggiornare i test in modo che corrispondano alle modifiche.

Se le tue regole sono esterne (una sorta di linguaggio di script o database sproc), dovrai avvolgerle in un test di integrazione e collegare i test di integrazione per l'esecuzione automatizzata. Sebbene non siano più test unitari, anche i test di integrazione sono abbastanza importanti e ti aiuteranno allo stesso modo dei test unitari per prevenire increspature impreviste dovute a una modifica delle regole di business.

Answer 3

Sembra che tu abbia delle regole commerciali e quindi dei clienti di quelle regole commerciali. Se quei due possono variare in modo indipendente, sarebbe saggio progettare la tua API di conseguenza.

Come presentato, la tua domanda sembra che possa essere risolta con un uso appropriato del modello di strategia. La strategia rappresenta le tue regole di business, quindi puoi testarle in un contesto puro senza preoccuparti del cliente.

Quando la regola aziendale cambia, può essere più sensato lasciare semplicemente la vecchia strategia così com'è (nel caso in cui sia necessaria in un secondo momento) e scrivere (e test unitario) una strategia completamente nuova che rappresenti la nuova regola aziendale .

Al termine della nuova strategia, è possibile sostituire la strategia nel client.

Quando l'unità testa il client, dovresti farlo contro una strategia di doppio test (come un Mock o Stub) per verificare che il client interagisca correttamente con la strategia senza dipendere da una particolare implementazione della strategia.

In questo modo, si ottiene una netta separazione delle preoccupazioni e si mantengono i test delle unità mantenibili. Obbedisci anche al principio aperto / chiuso.

Answer 4

Sembra corretto che il test fallisca se si cambiano le regole - questo è prevedibile.

È possibile semplificare il mantenimento del test in futuro se si utilizza un dispositivo di dati anziché valori hardcoded nel test stesso. Ad esempio, se il metodo deve restituire foo, è possibile averlo nel dispositivo. Quando si cambia la logica aziendale, si cambia semplicemente l'apparecchiatura e non sarà necessario eseguire il test unitario stesso.

Ovviamente, questo dipende fortemente dal tipo di logica che stai testando e potrebbe non essere sempre applicabile.

Answer 5

Penso che sia una domanda errata Business Rule e unit test sono in diversi livelli di astrazione. La regola aziendale è al livello più alto di astrazione (Business Modeling) ma il test unitario serve per testare un'unità di codice con il livello di astrazione più basso, quindi non puoi usare unit test per validare o verificare un business governare. Inoltre, una regola aziendale dopo l'analisi e la progettazione può influire su diverse unità di codice, pertanto non è possibile utilizzare unit test per convalidare o verificare una regola aziendale . Penso che puoi utilizzare il caso di test o lo scenario BDD per convalidare e verificare una regola aziendale.