CompSci 280 S2 2107 Introduction to Software Development JUnit

Today’s Agenda Topics: Reading: Introduction JUnit Testing Strategies Equivalence Partition Boundary Analysis Testing Reading: Software Engineering 10th Edition, Ian Somerville Chapter 8 Lecture20

1.Introduction Difficulties of testing Perception by some developers and managers: Testing is seen as a novice's job. Assigned to the least experienced team members. Done as an afterthought (if at all). "My code is good; it won't have bugs. I don't need to test it." "I'll just find the bugs by running the client program." Limitations of what testing can show you: It is impossible to completely test a system. Testing does not always directly reveal the actual bugs in the code. Testing does not prove the absence of errors in software. Lecture20

1.Introduction Unit Testing unit testing: Looking for errors in a subsystem in isolation. Generally a "subsystem" means a particular class or object. The Java library JUnit helps us to easily perform unit testing. The basic idea: For a given class Foo, create another class FooTest to test it, containing various "test case" methods to run. Each method looks for particular results and passes / fails. JUnit provides "assert" commands to help us write tests. The idea: Put assertion calls in your test methods to check things you expect to be true. If they aren't, the test will fail. Lecture20

1.Introduction JUnit - History Kent Beck developed the first xUnit automated test tool for Smalltalk in mid-90’s Beck and Gamma (of design patterns Gang of Four) developed JUnit on a flight from Zurich to Washington, D.C. Martin Fowler: “Never in the field of software development was so much owed by so many to so few lines of code.” Junit has become the standard tool for Test-Driven Development in Java (see Junit.org) Junit test generators now part of many Java IDEs (Eclipse, BlueJ, Jbuilder, DrJava) Xunit tools have since been developed for many other languages (Perl, C++, Python, Visual Basic, C#, …) Lecture20

2.JUnit & Eclipse To add JUnit to an Eclipse project, click: Project → Properties → Build Path → Libraries → Add Library... → Junit → JUnit 4 → Finish To create a test class Select File → New → JUnit Test Case Enter Name (test) Enter Class Under test (source class) Select method(s) Note: Name of class is important – should be of the form TestMyClass or MyClassTest JUnit can create stubs of method tests for you. JUnit runs tests and reports results Lecture20

2.JUnit & Eclipse Example 1: Calculator First, create a class in JUnit Calculator:- perform arithmetic operations add, subtract, multiply and divide public class Calculator { public int add( int number1, int number2 ) { return number1 + number2; } public int multiply( int number1, int number2 ) { return number1 * number2; ... Lecture20

2.JUnit & Eclipse Example 1: CalculatorTest Create a test class Enter name and class under Test, Select methods Note: A method with @Test is flagged as a JUnit test case. All @Test methods run when JUnit runs your test class. Lecture20

2.JUnit & Eclipse JUnit Assertion Methods Each method can also be passed a string to display if it fails: e.g. assertEquals("message", expected, actual) Flags discrepancies between the “expected” value and the result returned by the “class under test” method( ) assertTrue(test) fails if the boolean test is false assertFalse(test) fails if the boolean test is true assertEquals(expected, actual) fails if the values are not equal assertSame(expected, actual) fails if the values are not the same (by ==) assertNotSame(expected, actual) fails if the values are the same (by == assertNull(value) fails if the given value is not null assertNotNull(value) fails if the given value is null fail() causes current test to immediately fail Lecture20

2.JUnit & Eclipse Running a Test Right click it in the Eclipse Package Explorer at left; choose: Run As → JUnit Test The JUnit bar will show green if all tests pass, red if any fail. The Failure Trace shows which tests failed, if any, and why. @Test public void testAdd() { Calculator calc = new Calculator(); assertEquals(13, calc.add(3,10)); } Lecture20

2.JUnit & Eclipse Exercise 1 Complete all test cases: Multiple Subtract Divide Lecture20

2.Junit & Eclipse Fixture Tests may require common resources to be set up A test fixture is a fixed state of a set of objects used as a baseline for running tests. Examples of fixtures: Preparation of input data and setup/creation of fake or mock objects Loading a database with a specific, known set of data Copying a specific known set of files creating a test fixture will create a set of objects initialized to certain states. A fixture can be created by overriding the setUp and tearDown methods Note: setUp is invoked before each test, tearDown after Lecture20

2.JUnit & Eclipse Using Test fixtures Pattern follows programming by contract paradigm: Set up pre-conditions Exercise functionality being tested Check post-conditions public class CalculatorTest { private Calculator calc; /** * @throws java.lang.Exception */ @Before public void setUp() throws Exception { calc = new Calculator(); } @After public void tearDown() throws Exception { calc = null; @Test public void testAdd() { assertEquals(13, calc.add(3,10)); passed Lecture20

2.JUnit & Eclipse Things to Notice: Use the specific method signature – public void testWhatever() Allows them to be found and collected automatically by JUnit You cannot test every possible input, parameter value, etc. So you must think of a limited set of tests likely to expose bugs. Think about boundary cases positive; zero; negative numbers right at the edge of an array or collection's size Think about empty cases and error cases 0, -1, null; an empty list or array test behavior in combination maybe add usually works, but fails after you call remove make multiple calls; maybe size fails the second time only Lecture20

2.JUnit & Eclipse Example 2 A simple case: import java.util.*; public class SampleTest { private List<Integer> emptyList; @Before public void setUp() throws Exception { emptyList = new ArrayList<Integer>(); } @After public void tearDown() throws Exception { emptyList = null; @Test public void test() { assertEquals("Size of an empty list should be zero.", 0, emptyList.size()); assertTrue("An empty bowl should report empty.",emptyList.isEmpty()); Called before every test case method Called after every test case method Lecture20

2.JUnit & Eclipse Example 3: IntList Revisited: IntList public class IntListTest { IntList list ; @Before public void setUp() throws Exception { int[] input = { 1, 93, 2, 5, -17 }; list = new IntList(input); } @After public void tearDown() throws Exception { list = null; @Test public void testCountNumZeros() { assertEquals(0, list.countNumZeros()); Lecture20

2.Testing Strategies Automation Issues Some artifact testing cannot easily be automated (e.g., user interfaces) Some potential failure situations cannot be easily exercised (e.g., timing problems in real-time or concurrent software) Still a lot of work needed to support traceability: relationship between tests executed and client's requirements Lecture20

2.Testing Strategies Developing Good Tests Purpose of testing: Detect the presence of faults Detect faults by executing the code so that a failure is caused Assuming a fault exists: the higher the probability of causing a failure, the better the quality of the test Look at where faults are likely to be Consider quality of the test suite (individual tests of limited value) Consider the example… Lecture20

2.Testing Strategies Example Tab stops are specific locations on a line that are used for alignment. A character that appears after a tab character will be aligned to the nearest tab stop after the location of the tab character. One means of indicating tab stops is the number of characters that appear between tab stops. The example below shows, on the left, three lines of text with tab characters indicated by “\t”. On the right, the same lines of text are shown how they would appear after aligning to the tab stops, assuming the tab stops are every 4 characters. Consider implementing a method that provides the following functionality: Lecture20

2.Testing Strategies Example Inputs: string where the only whitespace characters are space and tab, integer indicating what tab stop to use Outputs: the number of space characters between the beginning of the string and the first non-whitespace character, assuming any tab characters are replaced by enough spaces corresponding to the tabstop Tab stop width = 4 spaces Examples: System.out.println(leadingSpacesCount("Testing \tis fun", 4)); System.out.println(leadingSpacesCount("\t\tTesting is fun", 4)); System.out.println(leadingSpacesCount("\tTesting", 4)); System.out.println(leadingSpacesCount(" \tTesting", 4)); + + + Testing 8 4 Lecture20

2.Testing Strategies Test Suite Quality Consider this test suite: Input = (“Fun", 4), Expected Output: 0 Is it improved by adding this test case? Input = (“Fun ", 4), Expected Output: 0 More test cases does not mean a better quality test suite Lecture20

2.Testing Strategies Choosing unit test cases The test cases should show that, when used as expected, the component that you are testing does what it is supposed to do. If there are defects in the component, these should be revealed by test cases. This leads to 2 types of unit test case: The first of these should reflect normal operation of a program and should show that the component works as expected. The other kind of test case should be based on testing experience of where common problems arise. It should use abnormal inputs to check that these are properly processed and do not crash the component. Lecture20

3.Equivalence Partition Partition testing, where you identify groups of inputs that have common characteristics and should be processed in the same way. You should choose tests from within each of these groups. Each of these classes is an equivalence partition or domain where the program behaves in an equivalent way for each class member. Lecture20

3.Equivalence Partition Examples Enter an integer between 4 and 10 Username (6-10 characters) Age (18-80 years, except 60-65 years) Invalid partition Valid partition Less than 4 e.g. 3, 2, 1, 0, -1… 4, 5, 6, 7, 8, 9 10 More than 10 e.g. 11, 12 … Invalid partition Valid partition Less than 6 e.g. 5, 4 .. 0 6, 7, 8, 9, 10 More than 10 e.g. 11, 12 etc Invalid partition Valid partition Less than 18 e.g. 17, 16…0 18, 19, … 59 60, 61 .. 65 66, 67.. 80 81, 82 … Lecture20

4.Boundary Analysis Testing Boundary testing is the process of testing between extreme ends or boundaries between partitions of the input values. Errors more likely to occur at extreme values of a variable So these extreme ends like Start- End, Lower- Upper, Maximum-Minimum are called boundary values and the testing is called "boundary testing". The basic idea in boundary value testing is to select input variable values at their: Minimum Just above the minimum A nominal value Just below the maximum Maximum Lecture20

4.Boundary Analysis Testing Examples Enter an integer between 4 and 10 Username (6-10 characters) Invalid partition – valid partition LOWER boundary Invalid partition – valid partition UPPER boundary Just below the boundary Just above the boundary 3 4 10 11 Invalid partition – valid partition LOWER boundary Invalid partition – valid partition UPPER boundary Just below the boundary Just above the boundary 5 characters 6 characters 10 characters 11 characters Lecture20