Fail early, fail often, succeed sooner!

Transcription

1 Fail early, fail often, succeed sooner!

2 Contents Beyond testing Testing levels Testing techniques TDD = fail early Automate testing = fail often Tools for testing Acceptance tests

3 Quality Erja Nikunen 3

4 Testing in different levels Unit testing Does a single object work? Integration testing Do multiple objects work together? Functional testing Does my application work? Acceptance testing Does the customer like my application? Regression testing Does a bug fix result in another fault in the application? Erja Nikunen 4

5 Techniques used in testing: white-box testing You know the code and you do your best to break the code grey-box testing You peek a little inside, e.g. know the architecture black box testing Focuses on input and output Erja Nikunen 5

6 Fail early i.e. Test-Driven Development practice Write a Test Case --> Watch it Fail --> Fix it --> Watch it pass --> Refactor the code Red Write a test to fail Tidy up, eliminate redundancies Refactor Green Make the code work Erja Nikunen 6

7 All failing Order of tests! Erja Nikunen 7

8 Pros and cons of TDD Writing tests first require you to really consider what you want from the code Creates a detailed specification (you understand the problem better) Less time spent in the debugger and when it is required you usually get closer to problem quickly Tells you whether your last change (or refactoring) has broken previously working code Allows the design to evolve and adapt to your changing understanding of the problem. Unit tests are simple and act as documentation for the code Improves quality and reduces bugs It s hard to learn and master You have to accept that some of the tests become obsolete (you have to delete them) You trust too much on your tests (remember: they are code just like any other code) You might try to fix the tests to show green by making ad hoc decisions forgetting to solve the real problem Erja Nikunen 8

9 Fail often i.e. test automation Automate the tests, and the tests can be run whenever Automate the tests, and free developers time to more challenging problems Automate the tests, and run them on a separate server not in the developer s setup Automate the tests, and you get a regression test suite Erja Nikunen 9

10 Fail often i.e. continuous integration Erja Nikunen 10

11 Continuous integration Continuous integration wraps version control, compilation and testing into a single repeatable process CI is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Erja Nikunen 11

12 Continuous integration server like Jenkins An example of a build history of a project Erja Nikunen 12

13 Continuous integration server like Jenkins Shows how tests are succeeded in separate builds Shows for example FindBugs static analyzer trend Dm: Found reliance on default encoding in sofa.model.mapbuilder.loadmap(): Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable. This will cause the application behaviour to vary between platforms. Use an alternative API and specify a charset name or Charset object explicitly. Erja Nikunen 13

14 Tools for unit testing There are hundreds of tools for different levels of testing One popular family is <x>unit family for different programming languages: Junit, Cunit, CppUnit, PHPUnit, PyUnit, JsUnit,. This family can be used for unit testing but also for integration testing/ functional testing Erja Nikunen 14

15 Unit Test Types Basic -- cases with small to medium sized inputs that are so simple they should obviously work. Calling every method in several ways Call assertequals(x, y) also in case it returns false Edge -- these are also cases that are simple but represent edge conditions -- the empty string, the empty list, etc. Advanced -- harder, more complex cases. Testing e.g. using the knowledge about the code, synchronization, complex algorithms, Erja Nikunen 15

16 <x>unit All of the <x>unit family of testing libraries rely on test cases where you basically make a proposition or claim of the behaviour of the program. You claim that if your programs gets a certain input, it will give back an output you want. These are called assertions. Junit is introduced in the Java testing session assertequals("testing clear ", 0, <calling clear and showing result>); Erja Nikunen 16

17 Assertions (many more available) fail(string message) Gives a message that test didn t go through asserttrue(string message, boolean condition) Checks if the condition is true assertfalse(string message, boolean condition) Checks if the condition is assertequals(object expected, Object actual) Checks if the parameters expected and actual have equal values Erja Nikunen 17

18 C and C++ CodeLite and Code::Blocks IDE s are introduced in the C testing session CodeLite has integrated UnitTest++ and this will also be introduced in C testing session CodeLite is not <x>unit family but has something similar: CHECK_EQUAL(10, i); CHECK_EQUAL("foo", str); Erja Nikunen 18

19 Acceptance testing Acceptance tests are black box test cases that are jointly written by a developer and a customer. An acceptance test is a concrete situation, or scenario, that the system might encounter when using the functionality of a user story. Erja Nikunen 19

20 Summary Change your perspective from developer to tester! Write tests as early as possible! Automate your testing as much as possible! Erja Nikunen 20

21 Further reading Head First Software Development, By: Dan Pilone & Russ Miles Publisher: O'Reilly Media, Inc. by Scott W. Ambler The Art of Agile Development: Test-Driven Development by James Shore Book/test_driven_development.html And many many more. Erja Nikunen 21

22 Questions?