Unit testing losse flarden

Wanneer je start met unit testing, zijn er diverse handvaten die je kunt gebruiken om unit testing te gebruiken in je applicaties.
In de test logica mag je geen gebruik maken van
- IFs statements
- Switch of case statements

- Vervolgens moet de test code die je opstelt herhaalbaar uitgevoerd kunnen worden.
- Vermijd Multiple Asserts.
- Integration test en een unit test moet je scheiden
Alle testen in de solution runnen, wanneer een test failed dan is er een probleem. Dus -> betere test
-> integration test
-> er is geen configuratie maar je moet de test vertrouwen
Een verschil tussen een unit test en integration test is dat bij een integration test configuration noodzakelijk is. (gebruik de postfix unittest en integrationtest voor de desbetreffende testen)

Bij 'gewone' code geldt al gebruik GEEN magic numbers, en dit gaat ook op voor test code.

Syntax method names (bij testen
- method name
-state undertest
- expected behavior
-> dat leidt tot 'Add_LessThanZero_ThrowException'.

Helper methods
- '_make' -> create
- '_change' -> update
- '_assert_'

- Alleen public testen. DIt is een contract naar buiten toe. Private/protected is voor intern gebruik en meer verandelijk.
- Incremental work! (stapje voor stapje)
- [setup] attribut, dit is uitgevoerd voor ELKE test
- start een fail test, de test mag niet blijven 'falen' als de productie code is aangepast
- TDD -> vind de bugs sneller
- Simple code kan bugs bevatten
- Test names zijn lang maar dit is readabily (documentatie)
- Duplicated de logic in de test is een probleem, je test de logica niet. Het eindresultaat is niet gecontroleerd de bug wordt gewoon opnieuw gecreereerd in de Assert.AreEqual. Unittest mag geen logica bevatten, zelfs geen string.Format etc.
- Verander nooit een test. Als een test niet goed is (failuing test). Tegenstrijdige requirements vraag na welke requirement geldig is.
- Code coverage