Unit Test Introduction Alexey Novakov 

Agenda • Status • Problem • Solution • Understanding • Benefits • Example • Tips 

Status: look around • Challenge: Projects more than people • IT Companies choose Agile approach • Real time user acceptance test 

Problems we have 

Problems we have • Fighting: Developer v/s Testers (Ping-pong) 

Problems we have • New Release is born bugs to prior Release HF 2 HF 1 

Problems we have • High risk to fix something quickly (we should launch new QA iteration) 

Problems we have • Unstable VCS source codes 

Problems we have • Deadly refactoring 

Solution 

Practices • Unit Tests – Test driven development • Continuous integration approach • Pair programming 

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. 

How does it work? 

Cycle 

TDD = Refactoring + TFD 

Understanding • Unit Test life cycle • Stubs/mock objects • Test tests business unit • Test motivates code to be low cohered • Good test tells the story 

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 

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 

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) 

Helpers to resolve dependencies 

Test double • Test stub • Mock object • Fake object • Test spy • Dummy object 

Test stub • Called modules need to be replaced • Tested module needs to be called 

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 

Other • Fake object (just escape of dependency) • Test spy (some kind of stub, write logs) • Dummy object (null, new Object ()) 

Benefits • Well-structured code, better design • Confidence in quality • Self-perfection • Reduces the need of manual tests • Safe refactoring 

“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 

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… 

Example: HOW-TO http://utplsql.sourceforge.net/Doc/fourstep.html 

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 

Choose program to test:2 • For example, some stored procedure or function • Identify the test cases: all possible cases and expected results 

Build a test package:3 • Package specification at file ut_.pks • Body at file ut_.pkb …… PROCEDURE ut_setup; PROCEDURE ut_teardown; PROCEDURE ut_myfunc1; …… • SQL> @ut_myfunc1.pks Package created. • SQL> @ut_myfunc1.pkb Package body created. 

Run your test:4 • SQL> exec utplsql.test (‘myfunc1', recompile_in => FALSE) SUCCESS: “myfunc1“ _____________________________________________________________ Or Failed: FAILURE: “reason”………… 

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; 

Test case: code1 PROCEDURE ut_betwnstr IS BEGIN utAssert.eq ( 'Typical valid usage', BETWNSTR( STRING_IN => 'abcdefg’, START_IN => 3, END_IN => 5 ), 'cde' ); 

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; 

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 

Tests not run waste away • Run your tests often. • Don’t let them get stale. • Rejoice when they pass. • Rejoice when they fail. 

Thank you!