The Atom of Software Testing: Unit Testing

A talk from FarmaTech Series.
Generally, I covered the points and questions in the following:

1. What's wrong with the test?
2. What is the secret of happiness in the testing?
3. Importance of software design
4. The relation between testing and software design
5. Why is it hard to write tests in the codebase?
6. The reasons we fail while writing the tests
7. The power of unit testing
8. Best practices of unit testing

Transcript

1. What’s wrong with testing? What is the secret of happiness in testing? THE ATOM OF SOFTWARE TESTING Unit Testing
2. ÖMER KORKMAZ software engineer Farmazon researcher Sabanci University omerkorkmazz omr_korkmaz alumni Ciceksepeti, Altinbas, Mercedes-Benz Turk omeerkorkmazz
3. Take a coffee and write some codes Deploy your codes and make your customers happy Take another coffee and refactor your codes WHAT IS ROUTINE ?
4. BUT, SUDDENLY... Fix bug1, bug2, bug3, .. Hurry up for hot-fix! Other bugs triggered, solve them!
5. WHAT’S WRONG WITH MY CODE ? Is my code dead ? Is my code alive ?
6. —Jack W. Reeves “Coding is design, testing and debugging are part of design.” http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf
7. is real software design SOURCE CODE 01
8. Sour code should not be DETESTABLE TESTABILITY 02
9. SOFTWARE DESIGN CODING TESTING
10. SOFTWARE DESIGN CODING TESTING REFACTORING
11. DEADLINE! Code is smelling.. I can’t write tests! Method is so complex. I don’t have time to write tests! Nobody pushes themselves to write tests! It works my local. Also, I completed manual tests!
12. —Edsger Dijkstra “Testing shows the presence, not the absence of bugs.”
13. UNIT INTEGRATION ACCEPTANCE LOAD SMOKE FUNCTIONAL PERFORMANCE MANUAL STATIC SYSTEM REGRESSION A / B TEST METHODOLOGIES ...
14. UNIT INTEGRATION ACCEPTANCE LOAD SMOKE FUNCTIONAL PERFORMANCE MANUAL STATIC SYSTEM REGRESSION A / B THE ATOM ! ...
15. WHAT IS UNIT TEST ? 01 Code typically written by developers to ensure that code meets requirements. 02 03 Isolate each part of the program and show individual parts behave as expected. Smallest unit of functionality and focuses on one particular feature
16. IN TRADITIONAL TESTING.. • Test the system as a whole. • Individual components rarely tested • Errors are undetected • Isolations of errors difficult to track
17. IN UNIT TESTING.. • Each part tested individually • All components tested at least once • Easy to detect errors • Smaller scope, fix defects easier
18. 01 FUNCTIONAL CORRECTNESS 01 It provides developers to make sure that whether the implemented functionality behaves as expected!
19. 01 CORRECTNESS OF OUTPUT DATA 02 Outputs of the methods should be obtained as usual.
20. 01 ERROR HANDLING 03 It is easy to detect the errors in complex units when testing each functionality as a small unit!
21. UNIT TEST DO NOT.. ACCESS THE NETWORK CONNECT TO DATABASE CREATE NEW THREADS ACCESS THE FILE SYSTEM
22. —Dave Cheney Project Member of Go Programming Language
23. BUT, UNIT TEST DO ? ACCESS THE NETWORK CONNECT TO DATABASE CREATE NEW THREADS ACCESS THE FILE SYSTEM MOCKS STUBS
24. —Martin Fowler “Mocks aren't stubs.” https://martinfowler.com/articles/mocksArentStubs.html
25. —Martin Fowler “Mocks are objects pre-programmed with expectations which form a specification of the calls they are expected to receive.” https://martinfowler.com/articles/mocksArentStubs.html
26. —Martin Fowler “Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test.” https://martinfowler.com/articles/mocksArentStubs.html
27. FASTER DEBUGGING AND DEVELOPMENT BETTER DESIGN REDUCE FUTURE COST WHY UNIT TESTS ?
28. UNIT TEST LIFE CYCLE Re-execute unit tests Fix defects Execute unit tests Make changes Code review Apply changes
29. GUIDELINES
30. Multiple runs of the test should consistently return true or consistently return false. CONSISTENCY 01 var time = DateTime.Now; string id = Guid.NewGuid(); ??
31. Tests should be PASS or FAIL No partial successful tests! ATOMIC 02 Test A should not depend on the outcome of Test B !
32. One test should be responsible for one use-case! SINGLE RESPONSIBILITY 03 One method multiple conditions MULTIPLE TESTS ! One behavior multiple methods ONE TEST !
33. Unit tests must be easy to • understand • read UNDERSTANDABILITY 04 Should_Foo_Return_Null_When_Throws_ Exception() ! Self-descriptive method and variable names !
34. Unit tests should not have conditional logics or loops! NO CONDITIONS 05 Do not use While or If statements ! Split into multiple tests rather than using “if” !
35. Catch only the expected type of exception NO EXCEPTION HANDLING 06 Fail test → undetectable exceptions !
36. Assertion messages should be clear when reading to see why test failed and what to do ASSERTIONS 07 “GetProductAsync should return null when throwing SQL exception” ! “CreateOrder should return true when created successfully” !
37. Do not create methods or properties used by only the tests! NO TEST LOGIC 08 Separate unit tests and product codes in different projects !
38. Create different test projects for every layer or assembly MODULE SEPARATION 09 FarmaLab.Tests.Domain FarmaLab.Tests.Manager !
39. While testing the methods, make sure boundary cases are tested! BOUNDARIES 10 BOUNDARY TESTING ROBUST BOUNDARY TESTING ! if(3<= age < 20) { //how to test the age? } !
40. When bug is reported, write some tests to reproduce the bugs and use the test as success criteria to fix it REPRODUCING BUGS 11 Sounds like TDD? • Write the fail test • Change it to pass ?
41. —Misko Hevery “The secret of testing is writing testable code.” https://twitter.com/mhevery
42. THANK YOU ! Questions & Answers