TESTINGANDTEST DRIVEN DEVELOPMENTLukasz Burdzanowski, KoJug 06.2011
Hitchheikers guide to...   part 1 – testing and tools     what is testing and why to test ?     what we test and how ? ...
Part 1 – Testing and tools
What is testing ?   Validation and verification of the current    implementation AND design   Emulation of application s...
What is testing ? – a little more…   Measurable contribution to “implementation” value   Testing does not equals writing...
Why to test ?   Makes us better professionals   Gives us – developers - valuable feedback   Brings quality assurance to...
Why we do not write tests ? (excuses)   It is slow and time consuming   Does not catch real bugs   I do not write buggy...
Why we do not write tests ? (excuses)   We have untestable design   Need to be refactored   I am programming GUI   I j...
Kinds of bugs  Logical, aka. classic bug – errors in logical   conditions, loops, etc.  Wiring   bugs – wrong data bindi...
Kinds of bugs           Depending on kind of bag,   difficulty of finding and fixing it varies…
Cost of fixing                Logical bugs are hard to find and fix. Also,                they are very common…  Wiring bu...
Kinds of tests  Depending on theirs kind,                   System wide teststests have different purpose. For true qualit...
Unit tests   Focus only on logical errors   Are related only to a single class or method    (isolation)   Are very fast...
Unit tests   Are short and brief, when fail you do not need    debugger to find the bug   Are aimed to help when refacto...
Integration tests   Test parts of application working together   Are aimed to catch bugs related to objects relations  ...
Integration tests   Can test boundary conditions unavailable in system    wide tests   Verify correctness of system inte...
System wide tests   Test correctness of the system as a whole   Emulate user behavior (real use cases coming from    ana...
What makes testing hard ?Four main factors of hard-to-test code:   The way object is created (constructor logic),   How ...
LoD ? SRP ? – hmm….Law of Demeter – one of rules of good object  oriented design which says:              “Only talk to yo...
LoD ? SRP ? – hmm….Single Responsibility Principle – usually referred as:       class should have ONE and ONLY ONE        ...
Why object construction makeslife harder ?   Intensive logic in constructor denies possibility of unit    testing and pre...
Does it really matter ?Look howdependency onclassimplementationmatters…We can not testwithout theEngine !
How to prevent ?   Do not bind object directly to an implementation,    use interfaces where possible,   Encapsulate obj...
How to prevent ?   Avoid intensive logic in constructors,   Avoid “fake API” when creating objects (like    .setup(), .i...
Class relations   Main types of relations are:     Instanced   objects – new     Passed   by objects – as method parame...
Untestables - class relations   Dependence on specific instance denies testing    (or at least makes it very painful…), ...
How to prevent ?   Favor interfaces over implementations,   Keep away from instanceOf,   Dependency injection makes lif...
Untestables – global state   Can cause most weird and hard to test situations,   Test isolation principle is violated ! ...
Global state – common flaws   Global state in JVM:     System.currentTime();     Math.radom();   Static methods – you ...
How to prevent ?   Do not use static – it can be usually easily distilled    into particular class or its behavior,   Ju...
Untestables – OOD violations   SRP – the more incoherent class is the harder is to    write tests. Highly incoherent clas...
How to prevent ?   Inability and difficulty of wiring unit test are signs    of bad architecture and/or bad design.   Co...
General flaws   Complicated conditionals (wide ifs or switch),   Depending heavily on Context objects, especially    glo...
General flaws – a little more   Hard dependency on external systems or modules,    impossible to mock,   Overuse of “uti...
Tools for testing   TestNG – successor to JUnit, testing framework    aimed to be powerful and easy to use,   Mockito – ...
Part 2 – Test Driven Development
What is TDD ?Test driven development brings alternative       approach to classical software             development cycle.
What is TDD ?TDD manifests itself in:     Iterational (evolutionary) approach to development,     Process emphasizing de...
TDD and its Test First DesignThe TDD bases on three key steps:   Test   Implementation   Refactoring
TDD in snapshot  You write business logic only when test is falling      If all is running – clean implementation     Deve...
TDD tools that help   Continuous Integration (Hudson, CruiseControl)   Test coverage tools, like Cobertura (EclEMMA),  ...
TDD tests first - benefits   Starting from tests gives you long-term benefits:       Helps keep your code clean       B...
TDD benefits – a few more    Overall implementation time is shortened    Tests are more through than in traditional appr...
TDD tests first - drawbacks   However there are some drawbacks:       TDD demands “different” approach to development,  ...
TDD drawbacks – few more…    Process itself does not excludes wrong implementation     (misinterpreted requirements),   ...
Key factors of testingThe main drawback of testing and TDD is its  dependence on two specific factors: people and  problem...
TDD myths   100% test coverage is required,    Unit tests are enough,                                         http://de.w...
A word for end   If its worth building, its worth testing.If its not worth testing, why are you wasting             your t...
Thanks for attention and listening
Upcoming SlideShare
Loading in...5
×

Testing and TDD - KoJUG

400

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
400
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Testing and TDD - KoJUG

  1. 1. TESTINGANDTEST DRIVEN DEVELOPMENTLukasz Burdzanowski, KoJug 06.2011
  2. 2. Hitchheikers guide to... part 1 – testing and tools  what is testing and why to test ?  what we test and how ?  what tools we can use ? part 2 – TDD  TDD as a development process  why to bother (benefits and drawbacks)
  3. 3. Part 1 – Testing and tools
  4. 4. What is testing ? Validation and verification of the current implementation AND design Emulation of application state in the very specific moments It is a skill, like any other
  5. 5. What is testing ? – a little more… Measurable contribution to “implementation” value Testing does not equals writing tests Yes, it is looking for bugs…
  6. 6. Why to test ? Makes us better professionals Gives us – developers - valuable feedback Brings quality assurance to our work Enables us with confidence
  7. 7. Why we do not write tests ? (excuses) It is slow and time consuming Does not catch real bugs I do not write buggy code – sure… Debugging is faster
  8. 8. Why we do not write tests ? (excuses) We have untestable design Need to be refactored I am programming GUI I just do not know how…
  9. 9. Kinds of bugs  Logical, aka. classic bug – errors in logical conditions, loops, etc.  Wiring bugs – wrong data bindings, incorrect injections  Rendering bugs – application output is messed, either UI or reports (unfortunately “tested” only by human)
  10. 10. Kinds of bugs Depending on kind of bag, difficulty of finding and fixing it varies…
  11. 11. Cost of fixing Logical bugs are hard to find and fix. Also, they are very common… Wiring bugs are relatively easy to find and fix, as their behavior is more verbose than logical one… Rendering bugs are usually easy to find and fix. It is really easy to SEE them…
  12. 12. Kinds of tests Depending on theirs kind, System wide teststests have different purpose. For true quality assurance, all tests are needed. The Integration testssmaller the test is – the more precise answer it brings. Unit testsThe catch is – the smaller the tests the more of them we need !
  13. 13. Unit tests Focus only on logical errors Are related only to a single class or method (isolation) Are very fast (only few ms)
  14. 14. Unit tests Are short and brief, when fail you do not need debugger to find the bug Are aimed to help when refactoring When passed – you are sure correct logical flow in class or method They are preferred way of testing !
  15. 15. Integration tests Test parts of application working together Are aimed to catch bugs related to objects relations Brief enough to be run before submitting to version control
  16. 16. Integration tests Can test boundary conditions unavailable in system wide tests Verify correctness of system integration with external systems practice physician patient
  17. 17. System wide tests Test correctness of the system as a whole Emulate user behavior (real use cases coming from analysis) Aimed to prove that system is capable to fulfill user (customer) requirement Can run noticeably long
  18. 18. What makes testing hard ?Four main factors of hard-to-test code: The way object is created (constructor logic), How classes interact with each other,  Global state,  Violations of OOD rules like LoD or SRP, LoD – Law of Demeter SRP – Single Responsibility Principle
  19. 19. LoD ? SRP ? – hmm….Law of Demeter – one of rules of good object oriented design which says: “Only talk to your best friends” ! bad: Car.getEngine().getFuelSystem().getTank().checkFuelLevel(); good: Car.getFuelLevel(); which calls Engine.getFuelLevel(); etc.
  20. 20. LoD ? SRP ? – hmm….Single Responsibility Principle – usually referred as: class should have ONE and ONLY ONE reason to change.
  21. 21. Why object construction makeslife harder ? Intensive logic in constructor denies possibility of unit testing and prevents testing If construction of the class depends entirely on implementation not interface, testing is impossible Complicated and time consuming constructions involves equally complicated test setup
  22. 22. Does it really matter ?Look howdependency onclassimplementationmatters…We can not testwithout theEngine !
  23. 23. How to prevent ? Do not bind object directly to an implementation, use interfaces where possible, Encapsulate object creation into factories, especially complex one
  24. 24. How to prevent ? Avoid intensive logic in constructors, Avoid “fake API” when creating objects (like .setup(), .init() method). Created object should be ready to use.
  25. 25. Class relations Main types of relations are:  Instanced objects – new  Passed by objects – as method parameters  Dependency to state (global) objects
  26. 26. Untestables - class relations Dependence on specific instance denies testing (or at least makes it very painful…), Cyclic dependencies will make code untestable, Local dependencies (method) are hard to test,
  27. 27. How to prevent ? Favor interfaces over implementations, Keep away from instanceOf, Dependency injection makes life easier,
  28. 28. Untestables – global state Can cause most weird and hard to test situations, Test isolation principle is violated ! (order of tests matters…) Multiple executions of tests can cause different results,
  29. 29. Global state – common flaws Global state in JVM:  System.currentTime();  Math.radom(); Static methods – you cannot change behavior using polymorphism, Singletons – root of all evil considering global state,
  30. 30. How to prevent ? Do not use static – it can be usually easily distilled into particular class or its behavior, Just avoid global state, If have to use global state - remember to “reset” it at the end of test method
  31. 31. Untestables – OOD violations SRP – the more incoherent class is the harder is to write tests. Highly incoherent class are hard to be unit tested. LoD – the deeper we go into object hierarchy the more difficult test setup is. Also, later refactoring becomes hard and painful.
  32. 32. How to prevent ? Inability and difficulty of wiring unit test are signs of bad architecture and/or bad design. Considering SRP, class responsibilities can be always distributed among more objects.
  33. 33. General flaws Complicated conditionals (wide ifs or switch), Depending heavily on Context objects, especially global flags, Static initialization blocks,
  34. 34. General flaws – a little more Hard dependency on external systems or modules, impossible to mock, Overuse of “utility” classes, * Final classes and methods
  35. 35. Tools for testing TestNG – successor to JUnit, testing framework aimed to be powerful and easy to use, Mockito – quite new mocking framework, simpler and easier in use than EasyMock,
  36. 36. Part 2 – Test Driven Development
  37. 37. What is TDD ?Test driven development brings alternative approach to classical software development cycle.
  38. 38. What is TDD ?TDD manifests itself in:  Iterational (evolutionary) approach to development,  Process emphasizing design over implementation,  Continuous integration and refactoring,
  39. 39. TDD and its Test First DesignThe TDD bases on three key steps: Test Implementation Refactoring
  40. 40. TDD in snapshot You write business logic only when test is falling If all is running – clean implementation Developer focuses on requirement before writing actual implementation Resulting implementation is more cohesive and lowly coupled code
  41. 41. TDD tools that help Continuous Integration (Hudson, CruiseControl) Test coverage tools, like Cobertura (EclEMMA), xUnit / mocking framework (Mocquito, EasyMock), Static analysis tools like Classcycle (JDepend),
  42. 42. TDD tests first - benefits Starting from tests gives you long-term benefits:  Helps keep your code clean  Brings feedback to design and architecture early,  Gives you constant and reliable feedback about development progress
  43. 43. TDD benefits – a few more  Overall implementation time is shortened  Tests are more through than in traditional approach
  44. 44. TDD tests first - drawbacks However there are some drawbacks:  TDD demands “different” approach to development,  Tests bring maintenance overhead,  TDD is as successful as written tests
  45. 45. TDD drawbacks – few more…  Process itself does not excludes wrong implementation (misinterpreted requirements),  With time, bunch of passing always green tests can lead to false belief about implementation
  46. 46. Key factors of testingThe main drawback of testing and TDD is its dependence on two specific factors: people and problem to be resolved. Where people are we, the one who are supposed to create application for customer and second factor is… The customer itself, time, resources andcomplexity of the problem…
  47. 47. TDD myths 100% test coverage is required, Unit tests are enough, http://de.wikipedia.org/wiki/Datei:Wolpertinger-praeparat.jpg Development effort is greater, and takes longer, TDD has long learning curve *
  48. 48. A word for end If its worth building, its worth testing.If its not worth testing, why are you wasting your time working on it?
  49. 49. Thanks for attention and listening

×