JUnit tes)ng. Elisa Turrini

Transcription

1 JUnit tes)ng Elisa Turrini

2 Automated Tes)ng Code that isn t tested doesn t work Code that isn t regression tested suffers from code rot (breaks eventually) If it is not automated it is not done! Boring Repe))ve Error- prone (for humans) Time consuming

3 Test Framework A test framework is a sokware tool for wri)ng and running unit- tests Provides reusable test func)onality which: Enables automa)c execu)on for regression tests Is standardized Easy to use Test report genera)on Programmer Friendly

4 What is xunit? A set of Frameworks for programming and automated execu)on of test- cases X stands for programming language Most Famous is J- UNIT for Java But exists for almost all programming language (C- unit, Cpp- Unit, DUnit, JUnit NUnit, ) and development plaxorms

5 xunit architecture All xunit frameworks share the following basic concepts: Test Runner Test case Test Fixtures Test Suites Test Result FormaZer Asser)ons

6 Test runner: an executable program that runs tests implemented using an xunit framework and reports the test results.

7 Test runner: an executable program that runs tests implemented using an xunit framework and reports the test results. Test case: a set of condi)ons under which a tester will determine whether a so#ware unit (i.e. individual unit of source code) is working as it was originally established for it to do. a class containing all test methods for a given sokware unit or func)on or class

8 Test Fixture: test context the set of precondi)ons or state needed to run a test.

9 Test Fixture: test context the set of precondi)ons or state needed to run a test. Test Suite: set of tests that all share the same fixture the order of the tests shouldn't mazer. Collec)on of related test cases Can be executed automa)cally in a single command

10 Structure of a Unit Test Setup Prepare an input Call a method Check an output Tear down

11 JUNIT TESTING

12 JUnit It is an instance of the xunit architecture for unit tes)ng frameworks. A programmer- oriented tes)ng framework for Java. JUnit is a simple framework to write repeatable tests JUnit4 Annota)ons Asser)ons

13 ECLIPSE DEMO

14 public class Calculator {!!! public int multiply(int x, int y) {! // the following is just an example! if (x > 999) {! throw new IllegalArgumentException!!!!!("X should be less than 1000");! }! return x * y;! }! }!

15 public class CalculatorTest public static void testsetup() {! public static void testcleanup() {! // Teardown for data used by the unit tests! = IllegalArgumentException.class)! public void testexceptionisthrown() {! Calculator tester = new Calculator();! tester.multiply(1000, 5);! public void testmultiply() {! Calculator tester = new Calculator();! assertequals("10 x 5 must be 50", 50, tester.multiply(10, 5)); }! }!

16 Tes)ng the methods in the unit vs. tes)ng unit behaviours One test should be responsible for one scenario only Test behaviour, not methods: One method, mul)ple behaviours - > Mul)ple tests One behaviour, mul)ple methods - > One test

17 Annota)ons In java, an annota)on is a form of syntac)c metadata that can be added to Java source code Annota)on provide data/informa)on about a program that is not part of the program itself Java annota)ons can be embedded in class files generated by the compiler and may be retained by the Java VM to be made retrievable at run- )me.

18 Junit iden)fies a method as a test (expected = Excep)on.class): Fails, if the method does not throw the named Fails, if the method takes longer than 100 milliseconds.

19 Junit This method is executed before each test. It is used to can prepare the test environment (e.g. read input data, ini)alize the This method is executed aker each test. It is used to cleanup the test environment (e.g. delete temporary data, restore defaults). It can also save memory by cleaning up expensive memory structures.

20 Junit This method is executed once, before the start of all tests. Methods annotated with this annota)on need to be defined as sta)c to work with This method is executed once, aker all tests have been finished. It is used to perform clean- up ac)vi)es. Methods annotated with this annota)on need to be defined as sta)c to work with JUnit.

21 Junit Ignores the test method. This is useful when the underlying code has been changed and the test case has not yet been adapted. Or if the execu)on )me of this test is too long to be included.

22 Assert statement JUnit provides sta)c methods in the Assert class to test for certain condi)ons. These asser-on methods typically start with assert and allow you to specify the error message the expected result the actual result. An asser-on method compares the actual value returned by a test to the expected value, and throws an Asser)onExcep)on if the comparison test fails.

23 Assert statement fail(string): Let the method fail. Might be used to check that a certain part of the code is not reached. Or to have a failing test before the test code is implemented. The String parameter is op)onal. asserttrue([message], boolean condi)on): Checks that the boolean condi)on is true. assertfalse([message], boolean condi)on): Checks that the boolean condi)on is false.

24 Assert statement assertequals([string message], expected, actual): Tests that two values are the same. Note: for arrays the reference is checked not the content of the arrays. assertequals([string message], expected, actual, tolerance) : Test that float or double values match. The tolerance is the number of decimals which must be the same.

25 Assert statement assertnull([message], object) Checks that the object is null. assertnotnull([message], object) Checks that the object is not null. assertsame([string], expected, actual) Checks that both variables refer to the same object. assertnotsame([string], expected, actual) Checks that both variables refer to different objects.

26 BEST PRACTICES

27 Unit Test Best Prac)ces 1. Consistent 2. Atomic 3. Single Responsibility 4. Self- descrip)ve 5. No condi)onal logic or loops 6. No excep)on handling 7. Informa)ve Asser)on messages 8. No test logic in produc)on code 9. Separa)on per business module 10. Separa)on per type

28 Consistent Mul)ple runs of the test should consistently return true or consistently return false, provided no changes were made on code Code that can cause problems: Dim currentdate as Date = Now() Dim value as Integer = New Random().Next

29 Unit Test Best Prac)ces 1. Consistent 2. Atomic 3. Single Responsibility 4. Self- descrip)ve 5. No condi)onal logic or loops 6. No excep)on handling 7. Informa)ve Asser)on messages 8. No test logic in produc)on code 9. Separa)on per business module 10. Separa)on per type

30 Atomic Only two possible results: PASS or FAIL No par)ally successful tests. Isola)on of tests: Different execu)on order must yield same results. Test B should not depend on outcome of Test A Use Mocks instead.

31 Unit Test Best Prac)ces 1. Consistent 2. Atomic 3. Single Responsibility 4. Self- descrip)ve 5. No condi)onal logic or loops 6. No excep)on handling 7. Informa)ve Asser)on messages 8. No test logic in produc)on code 9. Separa)on per business module 10. Separa)on per type

32 Single Responsibility One test should be responsible for one scenario only. Test behavior, not methods: One method, mul)ple behaviors à Mul)ple tests One behavior, mul)ple methods à One test

33 Single Responsibility Sub TestMethod() Assert.IsTrue(behavior1) Assert.IsTrue(behavior2) Assert.IsTrue(behavior3) End Sub Sub TestMethodCheckBehavior1() Assert.IsTrue(behavior1) End Sub Sub TestMethodCheckBehavior2() Assert.IsTrue(behavior2) End Sub Sub TestMethodCheckBehavior3() Assert.IsTrue(behavior3) End Sub

34 Unit Test Best Prac)ces 1. Consistent 2. Atomic 3. Single Responsibility 4. Self- descriplve 5. No condi)onal logic or loops 6. No excep)on handling 7. Informa)ve Asser)on messages 8. No test logic in produc)on code 9. Separa)on per business module 10. Separa)on per type

35 Self Descrip)ve Unit test must be easy to read and understand Variable Names Method Names Class Names No condi)onal logic No loops Self descrip)ve Name tests to represent PASS condi)ons: Public Sub CanMakeReserva)on() Public Sub TotalBillEqualsSumOfMenuItemPrices()

36 Unit Test Best Prac)ces 1. Consistent 2. Atomic 3. Single Responsibility 4. Self- descrip)ve 5. No condilonal logic or loops 6. No excep)on handling 7. Informa)ve Asser)on messages 8. No test logic in produc)on code 9. Separa)on per business module 10. Separa)on per type

37 No condi)onal logic or loops Test should have no uncertainty: All inputs should be known Method behavior should be predictable Expected output should be strictly defined Split in to two tests rather than using If or Case Tests should not contain While, Do While or For loops. If test logic has to be repeated, it probably means the test is too complicated. Call method mul)ple )mes rather than looping inside of method.

38 No condi)onal logic or loops Sub TestBeforeOrAfter() If before Then Assert.IsTrue(behavior1) ElseIf after Then Else Assert.IsTrue(behavior2) Assert.IsTrue(behavior3) End If End Sub Sub TestBefore() Dim before as Boolean = true Assert.IsTrue(behavior1) End Sub Sub TestAfter() Dim after as Boolean = true Assert.IsTrue(behavior2) End Sub Sub TestNow() Dim before as Boolean = false Dim after as Boolean = false Assert.IsTrue(behavior3) End Sub

39 No condi)onal logic or loops Sub Test() Dim result = mymethod(param); If result Then Assert.IsTrue(myMethod_A) Else Then Assert.IsTrue(myMethod_B) End If End Sub Sub TestBehavior1 () Dim result = mymethod(param1); Assert.IsTrue(result) Assert.IsTrue(myMethod_A) End Sub Sub TestBehavior2 () Dim result = mymethod(param2); Assert.IsFalse(result) Assert.IsTrue(myMethod_B) End Sub

40 Unit Test Best Prac)ces 1. Consistent 2. Atomic 3. Single Responsibility 4. Self- descrip)ve 5. No condi)onal logic or loops 6. No exceplon handling 7. Informa)ve Asser)on messages 8. No test logic in produc)on code 9. Separa)on per business module 10. Separa)on per type

41 No Excep)on Handling Indicate expected excep)on with azribute. Catch only the expected type of excep)on. Fail test if expected excep)on is not caught. Let other excep)ons go uncaught.

42 No Excep)on Handling <ExpectedException( MyException )> _ Sub TestException() mymethod(parameter) Assert.Fail( MyException expected. ) End Sub

43 Unit Test Best Prac)ces 1. Consistent 2. Atomic 3. Single Responsibility 4. Self- descrip)ve 5. No condi)onal logic or loops 6. No excep)on handling 7. InformaLve AsserLon messages 8. No test logic in produc)on code 9. Separa)on per business module 10. Separa)on per type

44 Informa)ve Asser)on Messages By reading the asser)on message, one should know why the test failed and what to do. Include business logic informa)on in the asser)on message (such as input values, etc.) Good asser)on messages: Improve documenta)on of the code, Inform developers about the problem if the test fails.

45 Unit Test Best Prac)ces 1. Consistent 2. Atomic 3. Single Responsibility 4. Self- descrip)ve 5. No condi)onal logic or loops 6. No excep)on handling 7. Informa)ve Asser)on messages 8. No test logic in produclon code 9. Separa)on per business module 10. Separa)on per type

46 No test logic in Produc)on Code Separate Unit tests and Produc)on code in separate projects. Do not create Methods or Proper)es used only by unit tests. Use Dependency Injec)on or Mocks to isolate Produc)on code.

47 Unit Test Best Prac)ces 1. Consistent 2. Atomic 3. Single Responsibility 4. Self- descrip)ve 5. No condi)onal logic or loops 6. No excep)on handling 7. Informa)ve Asser)on messages 8. No test logic in produc)on code 9. SeparaLon per business module 10. Separa)on per type

48 Separa)on per Business Module Create separate test project for every layer or assembly Decrease execu)on )me of test suites by splivng in to smaller suites Suite I - All Factories Suite II - All Controllers Smaller Suites can be executed more frequently

49 Unit Test Best Prac)ces 1. Consistent 2. Atomic 3. Single Responsibility 4. Self- descrip)ve 5. No condi)onal logic or loops 6. No excep)on handling 7. Informa)ve Asser)on messages 8. No test logic in produc)on code 9. Separa)on per business module 10.SeparaLon per type

50 Separa)on per Type Align Test Fixtures with type defini)ons. Reminder: Unit tests are separate from integra)on tests! Different purpose Different frequency Different )me of execu)on Different ac)on in case of failure

51 MOCK OBJECT

52 TesLng with stub and mock objects A unit test should test a class in isola)on but Java classes usually depend on other classes.

53 TesLng with stub and mock objects A unit test should test a class in isola)on but Java classes usually depend on other classes. Solu)on: you can use stubs or mock objects.

54 TesLng with stub and mock objects A tested object usually talks to other objects known as collaborators. To make unit tes)ng simpler, it is useful to replace the real coopera)ng objects with their fake replacements called test doubles. Test doubles can also be easily programmed with specific expecta)ons, such as recording any interac)ons they've had.

55 Test doubles Dummy - an empty object passed in an invoca)on (usually only to sa)sfy a compiler when a method argument is required) Stub - an object with hardcoded behavior suitable for a given test (or a group of tests) Mock - an object with the ability to have a programmed expected behavior, and verify the interac)ons occurring in its life)me (this object is usually created with the help of mocking framework) Spy - a mock created as a proxy to an exis)ng real object; some methods can be stubbed, while the un- stubbed ones are forwarded to the covered object

56 Stub vs. mock objects A stub class is an implementa)on for an interface or class with the purpose of using an instance of this stub class during tes)ng. Require a custom implementa)on A mock object is a dummy implementa)on for an interface or a class in which you define the output of certain method calls. are typically configured require less code to configure

57 Stub vs. mock objects Stub and mock objects can be passed to other objects which are tested. Your tests can validate that the class reacts correctly during tests, i.e., you can validate if certain methods on the mock object were called. This helps to ensure that you only test the class while running tests and that your tests are not affected by any side effects.

58 Mock object generalon You can create these mock objects manually (via code) or use a mock framework. The classical example for a mock object is a data provider. Mock objects can be provided to the class which is tested. Therefore the class to be tested should avoid any hard dependency on external data. Mock frameworks also allow to test the expected interac)on with the mock object.

59 Mock frameworks EasyMock jmock Mockito

60 MOCKITO

61 public interface ITranslator {!! public abstract String translate!!!(string fromlanguage, String tolanguage,!!!string word);! }!

62 public class Greeting {!! private ITranslator translator;!!! public Greeting(ITranslator translator){! this.translator = translator;! }!! public String sayhello!!!!!(string language, String name){!!!!string t = translator.translate!!!!!("english", language, "Hello");!!!!t = t + " " + name;!!!!return t;! }! }!

63 public void shouldtestgreetinginitalian(){! //setup! ITranslator mocktranslator =!!!!!mock(itranslator.class);! Greeting greeting =!!!!!new Greeting(mockTranslator);!!!!!when(mockTranslator.translate!!!!!("English", "Italian", "Hello")).!!!!!thenReturn("Ciao");!!!//execute!!!!String result =!!!!!greeting.sayhello("italian", Pippo );!! assertequals("ciao Pippo,result);!!!!//verify! verify(mocktranslator).translate!!!!!("english", "Italian", "Hello");! }!

64 TEST DRIVEN DESIGN

65 Unit Tes)ng vs. Test Driven Design

66 Unit Tes)ng vs. Test Driven Design Unit TesLng is the prac)ce of tes)ng your own code to understand whether it behaves the way you want or not.

67 Unit Tes)ng vs. Test Driven Design Unit TesLng is the prac)ce of tes)ng your own code to understand whether it behaves the way you want or not. Test Driven Design (TDD) is the discipline of using "Unit Tes)ng" when you design the sokware.

68 Bibliografy hzp://junit.sourceforge.net hzp://people.cs.aau.dk/~bnielsen/tov08/lek)oner/unit- intro.pdf hzp:// hzp:// tes)ng- concepts- and- best- prac)ces hzp:// tes)ng- best- prac)ces hzp://en.wikipedia.org/wiki/xunit hzp://code.google.com/p/mockito/ hzp:// hzp://refcardz.dzone.com/refcardz/mockito

69 Tutorials hzp:// ar)cle.html hzp://courses.cs.washington.edu/courses/ cse143/11wi/eclipse- tutorial/junit.shtml hzp:// tutorials- and- example/