Quando scrivere Test unitari: c'è qualche elenco di termini per prendere la decisione giusta [chiuso]

5

Per scrivere i test delle unità, dobbiamo scrivere bit di codice aggiuntivi. Per diversi progetti facciamo test unitari e per diversi progetti non lo facciamo.

In qualità di caposquadra, ho difficoltà a prendere la decisione giusta.

Esiste o elenca termini in base ai quali posso prendere la decisione giusta, indipendentemente dal fatto che effettueremo o meno test unitari?

EDIT: Si prega di fornire un commento mentre si vota la domanda. Mi aiuterà a migliorare la mia domanda.

    
posta Md Mahbubur Rahman 07.02.2013 - 17:55
fonte

2 risposte

8

Come regola generale, direi che dovrebbe scrivere test di unità per tutto il codice scrivi . Ci possono essere casi in cui non hai bisogno di testare qualcosa, ma avrei pensato che sarebbe stato insolito e improbabile.

Il vantaggio di avere dei test per il tuo codice è sapere quando alcune funzionalità cambiano, ovviamente è necessario avere una buona copertura e test ben scritti di cui si abbia fiducia. Basta avere un test che copra del codice non è una garanzia che il tuo codice è corretto / impeccabile In realtà un test negativo può essere peggio di nessun test. Ma questa è davvero una domanda diversa.

I pity the fool who doesn't write unit tests
any tests are better than zero tests. And isn't unit testing just a barely more formal way of doing the ad-hoc testing we've been doing all along? I think Fowler said it best:

Whenever you are tempted to type something into a print statement or a debugger expression, write it as a test instead. I encourage developers to see the value of unit testing; I urge them to get into the habit of writing structured tests alongside their code. That small change in mindset could eventually lead to bigger shifts like test-first development-- but you have to crawl before you can sprint.

    
risposta data 07.02.2013 - 18:02
fonte
4

The Way of Testivus dice quindi in merito a quando scrivere test unitari:

The best time to test is when the code is fresh

Your code is like clay.
When it’s fresh, it’s soft and malleable.
As it ages, it becomes hard and brittle.

If you write tests when the code is fresh
and easy to change, testing will be easy
and both the code and the tests will be strong.

La cosa fondamentale da prendere in considerazione è che scrivi codice all'inizio del processo quando puoi ancora pensare su cosa sta facendo il codice. Quando lo fai, pensi a cosa è testabile e cosa non lo è. Un altro po 'dalla Via del Testamento ...

Think of code and test as one

When writing the code, think of the test.
When writing the test, think of the code.

When you think of code and test as one,
testing is easy and code is beautiful.

Una cosa che mi piace di The Way of Testivus piuttosto che più affermazioni dogmatiche è che richiama specificatamente il dogma e dice che non si blocca su di esso. Scrivere il test è più importante delle seguenti regole definite in pietra.

Scrivi test.
Scrivi presto i test.
Un test scritto scadente è meglio di nessun test.

    
risposta data 07.02.2013 - 19:18
fonte

Leggi altre domande sui tag