Introduction to Unit Testing

Transcript

1. Unit Test Introduction Alexey Novakov
2. Agenda • Status • Problem • Solution • Understanding • Benefits • Example • Tips
3. Status: look around • Challenge: Projects more than people • IT Companies choose Agile approach • Real time user acceptance test
4. Problems we have
5. Problems we have • Fighting: Developer v/s Testers (Ping-pong)
6. Problems we have • New Release is born bugs to prior Release HF 2 HF 1
7. Problems we have • High risk to fix something quickly (we should launch new QA iteration)
8. Problems we have • Unstable VCS source codes
9. Problems we have • Deadly refactoring
10. Solution
11. Practices • Unit Tests – Test driven development • Continuous integration approach • Pair programming
12. TDD Initiator • Kent Beck is an American software engineer and the creator of the Extreme Programming and Test Driven Development software development methodologies. Beck was one of the 17 original signatories of the Agile Manifesto in 2001. • Kent Beck has an M.S. degree in computer science from the University of Oregon. He has pioneered software design patterns, the rediscovery of test-driven development, as well as the commercial application of Smalltalk. Beck popularized CRC cards with Ward Cunningham and along with Erich Gamma created the JUnit unit testing framework. • Kent lives in Medford, Oregon and work at Facebook.
13. How does it work?
14. Cycle
15. TDD = Refactoring + TFD
16. Understanding • Unit Test life cycle • Stubs/mock objects • Test tests business unit • Test motivates code to be low cohered • Good test tells the story
17. Unit Test Concept 1) Set up (initialization, factory) 2) Test method - driver 3) Tear down (resource release) Test Suite (1..n cases) Test Case (1..n methods) 1) Set up 2) Test method - driver 3) Tear down
18. How to verify test passing • Assert statement - to check specific output data • Check (particular) Exception has (or not) been thrown, can be done via Assert as well
19. How to verify test passing • Assert statement - to check specific output data • Check Exception has (or not) been thrown, can be done via Assert as well • assertEquals(expected, actual) • assertEquals(message, expected, actual) • assertEquals(expected, actual, delta) • assertEquals(message, expected, actual, delta) • assertFalse(condition) • assertFalse(message, condition) • assertNotNull(object) • assertNotNull(message, object) • assertNotSame(expected, actual) • assertNotSame(message, expected, actual) • assertNull(object) • assertNull(message, object) • assertSame(expected, actual) • assertSame(message, expected, actual) • assertTrue(condition) • assertTrue(message, condition) • fail() • fail(message) • failNotEquals(message, expected, actual) • failNotSame(message, expected, actual) • failSame(message)
20. Helpers to resolve dependencies
21. Test double • Test stub • Mock object • Fake object • Test spy • Dummy object
22. Test stub • Called modules need to be replaced • Tested module needs to be called
23. Mock object • Mock object is used as a substitute object in a situation where a stud is called for • It does verification of output data
24. Other • Fake object (just escape of dependency) • Test spy (some kind of stub, write logs) • Dummy object (null, new Object ())
25. Benefits • Well-structured code, better design • Confidence in quality • Self-perfection • Reduces the need of manual tests • Safe refactoring
26. “Bad” statistics • 3 weeks development • 2 weeks QA iteration • 6 build of package • About 40 items, ~20(half) NotDone/NotFixed • Fix on a fly to QA environment • Issues existed on pre-production environment for key features • Every bug-fix ~1hour • Every package rebuild ~30hour
27. Ready-made tools • Java: JUnit, TestNG, DbUnit • PL/SQL: utPL/SQL, pl/unit, pluto-test- framework • C++: CppTest, CUTE, CPUnit • And for many other languages…
28. Example: HOW-TO http://utplsql.sourceforge.net/Doc/fourstep.html
29. Install on db instance:1 • Create special schema or install by system user • Execute: SQL> @ut_i_do install • To uninstall: SQL> @ut_i_do uninstall
30. Choose program to test:2 • For example, some stored procedure or function • Identify the test cases: all possible cases and expected results
31. Build a test package:3 • Package specification at file ut_<myFunc1>.pks • Body at file ut_<myFunc1>.pkb …… PROCEDURE ut_setup; PROCEDURE ut_teardown; PROCEDURE ut_myfunc1; …… • SQL> @ut_myfunc1.pks Package created. • SQL> @ut_myfunc1.pkb Package body created.
32. Run your test:4 • SQL> exec utplsql.test (‘myfunc1', recompile_in => FALSE) SUCCESS: “myfunc1“ _____________________________________________________________ Or Failed: FAILURE: “reason”…………
33. Example: Code CREATE OR REPLACE FUNCTION betwnStr ( string_in IN VARCHAR2, start_in IN INTEGER, end_in IN INTEGER ) RETURN VARCHAR2 IS BEGIN RETURN ( SUBSTR ( string_in, start_in, end_in – start_in + 1 ) ); END;
34. Test case: code1 PROCEDURE ut_betwnstr IS BEGIN utAssert.eq ( 'Typical valid usage', BETWNSTR( STRING_IN => 'abcdefg’, START_IN => 3, END_IN => 5 ), 'cde' );
35. Test case: code2 utAssert.isnull ( 'NULL start', BETWNSTR( STRING_IN => 'abcdefg’, START_IN => NULL, END_IN => 5 ) ); utAssert.isnull ( 'NULL end', BETWNSTR( STRING_IN => 'abcdefg’, START_IN => 2, END_IN => NULL ) ); utAssert.isnull ( 'End smaller than start', BETWNSTR( STRING_IN => 'abcdefg’, START_IN => 5, END_IN => 2 ) ); utAssert.eq ( 'End larger than string length', BETWNSTR( STRING_IN => 'abcdefg’, START_IN => 3, END_IN => 200 ), 'cdefg' ); END ut_BETWNSTR;
36. Philosophy • If you write code, write tests. • Don’t get stuck on unit testing dogma. • Embrace unit testing karma. • Think of code and test as one. • The test is more important than the unit. • The best time to test is when the code is fresh. • An imperfect test today is better than a perfect test someday. • An ugly test is better than no test. • Sometimes, the test justifies the means. • Only fools use no tools. • Good tests fail. The Way of Testivus - by Alberto Savoia
37. Tests not run waste away • Run your tests often. • Don’t let them get stale. • Rejoice when they pass. • Rejoice when they fail.
38. Thank you!