1 / 31

Junit Testing

Junit Testing. M. Taimoor Khan taimoorkhan@ciit-attock.edu.pk Adapted from Swinburne Notes, . Content. Client expectations When should testing start? A good design helps Different ways to Test Print Statements Debuggers Walkthroughs Unit Testing. Expectations & Reality.

adele
Download Presentation

Junit Testing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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); }

More Related