Download
junit testing n.
Skip this Video
Loading SlideShow in 5 Seconds..
Junit Testing PowerPoint Presentation
Download Presentation
Junit Testing

Junit Testing

149 Views Download Presentation
Download Presentation

Junit Testing

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Junit Testing M. Taimoor Khan taimoorkhan@ciit-attock.edu.pk Adapted from Swinburne Notes,

  2. Content • Client expectations • When should testing start? • A good design helps • Different ways to Test • Print Statements • Debuggers • Walkthroughs • Unit Testing

  3. Expectations & Reality • Clients Expect • Software will work as specified • Software will be reliable • Software will be safe • Assignments will be tested • Reality • Software is extremely complex • Software frequently does not do what it should • Software bugs have led to the death of people • Most software is delivered with many faults (look at Microsoft) • We can do a lot better http://www.cse.lehigh.edu/~gtan/bug/softwarebug.html

  4. When do you start testing?

  5. Big Bang Approach • Write all the Code • Test at end This is rubbish

  6. Ideas • Some Software Development Life Cycles say • Design tests before you develop code • For software developed in this subject you must • Design with testing in mind • Plan how to test • Test as you go • Retest after you make changes • Test at method / class / system levels • Develop in small increments and test each increment

  7. Software Engineers are particular about their jargon • Early errors are usually syntax errors. • The compiler will spot these. • Later errors are usually logic errors. • The compiler cannot help with these. • Also known as bugs. • Some logical errors have no immediately obvious manifestation. • Commercial software is rarely error free. • http://www.csse.monash.edu.au/~jonmc/CSE2305/Topics/12.24.SWEng3/html/text.html

  8. Design Time • We can lessen the likelihood of errors through the use of • Encapsulation. • Hide inner workings, provide public interface • http://en.wikipedia.org/wiki/Encapsulation_(computer_science) • Modularization • Divide into packages/classes/methods • Documentation • What should it do? Write it down (put it in the code as well, Javadoc) • The higher the coupling between software the more difficult to test it will be. (Reliance on other software) • Cohesive units are much easier to test

  9. Modularization and Interfaces • Applications often consist of different modules. • One benefit is different teams can work on them. • But, The interface between modules must be clearly specified. • Increases the likelihood of successful integration. • Supports independent concurrent development. • Each module does not need to know implementation details of the other. • User controls could be a GUI or a hardware device. • Logic could be hardware or software.

  10. Example of Interface Definition // Return the value to be displayed. public int getDisplayValue(); // Call when a digit button is pressed. public void numberPressed(int number); // Call when a plus operator is pressed. public void plus(); // Call when a minus operator is pressed. public void minus(); // Call to complete a calculation. public void equals(); // Call to reset the calculator. public void clear();

  11. During Development • Think very carefully about the order in which you develop the software • Develop so small parts can be tested • This occurs not only at a macro level in terms of the order we develop packages • But also at a micro level, the order we develop classes and • Even lower down, the order in which we develop methods

  12. What is testing & debugging? • Something we often ignore • Searches for the presence of errors. • Debugging searches for the source of errors. • The manifestation of an error may well occur some ‘distance’ from its source. • Don’t give testing to the least skilled person in your group!

  13. You must know what you are going to TEST • Black box level • Understand what the unit should do – its contract. • You will be looking for violations. • Use positive tests and negative tests. • White box level • Test boundaries. • Zero, One, Full. • Search an empty collection. • Add to a full collection.

  14. There are many ways to test • Print statements • Debuggers • Walkthroughs • Code Inspection • Unit testing (within BlueJ) • Test automation Unit = “Part of the Program”, method, class

  15. Print statements Highly Recommended • The most popular technique. • No special tools required. • All programming languages support them. • Turning off and on requires forethought. Turn off before submitting assignment

  16. Debuggers • Debuggers are both • Language-specific • Environment-specific. • BlueJ has an integrated debugger. • Support breakpoints. • Step and Step-into controlled execution. • Show sequence of calls (stack). • Show Object state.

  17. Debugging • It is important to develop code-reading skills. • Debugging will often be performed on others’ code. • Techniques and tools exist to support the debugging process.

  18. Verbal walkthroughs • Explain to someone else what the code is doing. • They might spot the error. • The process of explaining might help you to spot it for yourself.

  19. Manual walkthroughs • Relatively underused. • A low-tech approach. • More powerful than appreciated. • Get away from the computer! • ‘Run’ a program by hand. • High-level (Step) or low-level (Step into) views.

  20. Code Inspections • Planning: The inspection is planned by the moderator. • Overview meeting: The author describes the background of the work product. • Preparation: Each inspector examines the work product to identify possible defects. • Inspection meeting: During this meeting the reader reads through the work product, part by part and the inspectors point out the defects for every part. • Rework: The author makes changes to the work product according to the action plans from the inspection meeting. • Follow-up: The changes by the author are checked to make sure everything is correct. • http://en.wikipedia.org/wiki/Software_inspection

  21. Unit testing • Each unit of an application may be tested. • Method, class, module (package in Java). • Can (should) be done during development. • Finding and fixing errors early lowers development costs (e.g. programmer time). • A test suite is built up that can be reused

  22. Unit testing within BlueJ This is a manual process , not very efficient and ONLY APPLIES TO BlueJ • Objects of individual classes can be created. • Individual methods can be invoked. • Inspectors provide an up-to-date view of an object’s state. Explore through the diary-prototype project in BlueJ

  23. Test automation • Good testing is a creative process, but ... ... thorough testing is time consuming and repetitive. • Regression testing involves re-running tests. • Use of a test rig or test harness can relieve some of the burden. • Classes are written to perform the testing. You have already been doing this.

  24. Test Automation • Involves • Unit testing • JUnit • Regression testing • Test cases • Test classes • Assertions • Fixtures

  25. JUnit • JUnit is a Java test framework • Test cases are methods that contain tests • Test classes contain test methods • Assertions are used to assert expected method results • Fixtures are used to support multiple tests • (Objects ready to use in a predefined state)

  26. Choosing a test strategy • Be aware of the available strategies. • Choose strategies appropriate to the point of development. • Automate whenever possible. • Reduces tedium. • Reduces human error. • Makes (re)testing more likely.

  27. Review • Errors are a fact of life in programs. • Good software engineering techniques can reduce their occurrence. • Testing and debugging skills are essential. • Make testing a habit. • Automate testing where possible. • Practice a range of debugging skills.

  28. References • http://startswithabang.com/wp-content/uploads/2008/05/bigbang.jpg • http://blueroof.files.wordpress.com/2007/04/ignore.png • http://en.wikipedia.org/wiki/Encapsulation_(computer_science) • http://en.wikipedia.org/wiki/Modular_programming • http://www.cs.colorado.edu/~kena/classes/5828/s07/lectures/04/EarlyDefectRemoval.png • http://en.wikipedia.org/wiki/Software_inspection

  29. A simple example public void test() { int sum = 1; for (inti = 0; i <= 4; i++); { sum = sum + 1; } System.out.println("The result is: " + sum); System.out.println("Double result: " + sum+sum); } What is the output?

  30. Results Which one is printed? The result is: 5 The result is: 6 The result is: 11 The result is: 2 Double result: 12 Double result: 4 Double result: 22 The result is: 2 Double result: 22 Double result: 66

  31. Code snippet of the day public void test() { int sum = 1; for (int i = 0; i <= 4; i++); { sum = sum + 1; } System.out.println("The result is: " + sum); System.out.println("Double result: " + sum+sum); }