1. What is Unit Testing? How TDD Works? Tsvyatko Konov Telerik Corporation www.telerik.com

3. Public bool IsLoginOK(string user, string password) { //………………………… }

4. Public bool IsLoginOK(string user, string password) { //………………………… } Should return true when… Should return false when…

5.  Easier to find bugs  Easier to maintain  Easier to understand  Easier to Develop source flickr.com

6.  Not structured  Not Repeatable  Not on all your code  Not easy to do as it should be  A framework is missing

7.  Original was for SmallTalk  Kent Beck and Erich Gamma  Ported to Various languages and platforms  JUnit, CppUnit, DUnit, VBUnit, RUnit, PyUnit, Sunit, HtmlUnit, …  Good list at www.xprogramming.com  Standard test architecture

8.  Write Tests  Make it easy to create and organize tests  Reference an assembly, spread some attributes, you’re done  Run Tests  Allow running all of our tests, a group or just one.  From command line or GUI  Review Results  Immediate Pass/Fail feedback  Details on each failure

9.  NUnit  XUnit  MbUnit  Team System Unit Testing

12.   Arrange all necessary preconditions and inputs.   Act on the object or method under test.   Assert that the expected results have occurred.

13.  TestClass  TestMethod  TestInitialize  TestCleanup  ExpectedException  Ignore  Description

14.  TDD = Test First Development + Refactoring  Make it Fail  No code without a failing test  Make it Work  As simply as possible  Make it Better  Refactor

15. make a little change (refactor) add a test run the tests [Pass] [Fail] [Development continues] [Development stops]

16. TDD + Code Coverage

17.  TDD = Test First Development + Refactoring  But what are the advantages?

18.  TDD shortens the programming feedback loop  TDD provides detailed specification (tests)  TDD promotes the development of high- quality code  TDD provides concrete evidence that your software works

19.  (a) Traditional waterfall development process  (b) Evolutionary development process (EVO).

20.  TDD “speaks” to programmers  TDD provides very finely grained concrete feedback on the order of minutes  TDD helps to ensure that your design is clean by focusing on creation of operations that are callable and testable  TDD supports evolutionary development.

21.  Defect Rate  Long term and short term affect  Productivity  Lines of code per month impact  Test Frequency  Ratio of interactive to automated  Design  Design robustness  Integration  Smoothness of code integration

22.  Defect Rate  50% improvement  Productivity  Below initial estimates (<400 LOC)  Test Frequency  86% of tests were automated  Design  Aided in late changes  Integration  Testing made problems surface early

23.  Results from Microsoft Study  Tested 4 products  Pre-release defect density reduces - 40% to 90%  Increase in initial development time - 15 – 35%

24.  Think through the requirement  Think about the design and usability of the API  There’s never time to write it afterwards  You write much less tests (if at all) otherwise

25.  Make sure the test does not have a bug  Make sure you’re testing the right thing  Define a small problem to solve  When the test passes, you are done  If you can’t write that test, you may  Not understand the requirement  Have over designed things (not testable)  Not have a small enough problem to solve

26.  Force you to write more tests you hadn’t considered  Simpler solutions are easier to maintain  Better code coverage of tested code

27.  Constantly improve the design of the code  Unit tests act as safety net  Remove duplication, improve readability and maintainability  You’ll need to when things change (requirements, your understanding of them, other factors..)

28.  Potential “Production Bugs” reduced by up to 90% - > more stable product  Better designed interfaces  API Documentation  Safety net for past and future  Happier customer  Happier coders

29.  It’s not easy to learn  Dealing with legacy code  Requires a lot of discipline  You have to want to do it  But once you do…  It gets easier and easier  It’s a hard habit to let go

30.  Making your tests trustworthy  Creating maintainable tests  Readable tests – last but not least!

31. Questions?