1. CS 160: Software Engineering November 12 Class Meeting Department of Computer Science San Jose State University Fall 2014 Instructor: Ron Mak www.cs.sjsu.edu/~mak

2. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak Tesla Headquarters Visit 2 BourneJosephstudentComputer Engineering CairesDebraprofessorComputer Science DhillonGurleenstudentComputer Engineering DimovDimastudentComputer Science EstellKhalilstudentComputer Engineering FloresPedrostudentComputer Science GallegosKevinstudentComputer Engineering InzunzaOscarstudentComputer Science JoshiHardikstudentComputer Science KangJackstudentComputer Science KannanPrakasamstudentComputer Science KoumisAlexstudentComputer Engineering LongCamillestudentComputer Engineering MakRonprofessorComputer Science NarahariSrikanthstudentComputer Science NguyenDuystudentComputer Engineering PatelJaystudentComputer Science ShahShukanstudentComputer Science ThorpeDavidstudentComputer Science TorrefrancaDanielstudentComputer Engineering TranDucstudentComputer Engineering TranHungstudentComputer Engineering TsuiHelenstudentComputer Engineering WeiEileenstudentComputer Science WongNelsonstudentComputer Engineering Friday, November 14 at 2:00 3500 Deer Creek Road Palo Alto

3. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 3 Code Reviews  Purpose: To explain orally in detail a piece of code that you've written for your project.  What is the context of the code? Example: This is the servlet that registers a new user.  How does the code work? What algorithm did you chose? Why?  Reviewers: Fellow software developers. The reviewers will look for problems, make suggestions, etc.

4. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 4 Code Reviews, cont’d  Limit the amount of code (including comments) to something a reviewer can read and digest beforehand in about one hour.  What code to pick for review: Some code that you want reviewed, either because it's a key component of your product, or it was difficult to write, or it uses a clever algorithm, etc. Some code that you need help from your colleagues.

5. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 5 Code Reviews, cont’d  Time limit of 20 minutes.  About ½ of the time explaining the code.  About ½ of the time interacting with the reviewers.  A “real life” code review can last for hours spread over several days.  Reviewers need to get a copy of the code to be reviewed at least one day in advance.

6. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 6 Code Reviews: Monday, Nov. 17  Section 3 List Ninja Merge Monkeys Noisy Coders  Section 4 Activate League of Ordinary Gentlemen Not Applicable  Email me your source code to be reviewed by Friday, Nov. 14.

7. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 7 Code Reviews: Wednesday, Nov. 19  Section 3 Code Monsters 160 Zaibatsu Tin Bullet  Section 4 Quiet Coders Surprise Error Dream Team  Email me your source code to be reviewed by Monday, Nov. 17.

8. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 8 One Month to Go!  Review your project schedule.  Prioritize tasks and put off lower priority ones.  Agree upon a “release candidate” (RC) and make that your primary goal. Define the next RC when you’ve achieved the current one.  Each RC should be something you can turn in. It’s better to turn in a working application, even if it doesn’t have all the features, than one that doesn’t work at all.

9. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 9 One Month to Go! cont’d  Stability is critical.  Do frequent builds.  Be wary of major last-minute changes.  Your final project documentation can include “release notes” that describe any missing features.

10. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 10 The Cost of Correcting Defects  The cost to correct a defect increases the later it is corrected. 50 to 200 times more expensive to correct later than sooner An iterative (agile) process catches defects soon after they’re made.

11. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 11 Make Small Mistakes Early  Make a carefully planned series of small mistakes early to avoid making unplanned large mistakes later. Example: Create four conceptual design alternatives in the beginning and throw three of them away = 3 small early mistakes. Example: Fail to do adequate design in the beginning and later rewrite the code three times = 3 large expensive mistakes.  Make and correct early mistakes because they cost much less than late mistakes.

12. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 12 Unit Testing  Each unit test focuses on components created by a developer.  Developers create test cases to do unit tests. Done by a developer before committing the code to the source repository. Easier to find and fix bugs when there are fewer components. Bottom-up testing.

13. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 13 Unit Testing: Test Cases  Test case: A set of input values for the unit and a corresponding set of expected results.  A test case can be run within a testing framework (AKA test bed, test harness) consisting of a test driver and one or more test stubs.

14. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 14 Unit Testing: Test Cases, cont’d  Test driver: Simulates the part of the system that calls the unit.  Calls the unit and passes in the input values.  Test stub: Simulates the components that the unit depends on. When called by the unit, a test stub responds in a correct or “reasonable” manner.

15. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 15 Unit Testing: Testing Framework UNIT (What’s being tested) TEST DRIVER calls TEST STUB calls TEST STUB calls TEST STUB calls

16. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 16 Writing and Running Unit Tests  Developers are responsible for writing unit tests during each iteration. Whenever you design and write a new class, write a unit test that tests that class.  Developers are responsible for running the unit tests.

17. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 17 JUnit  A popular tool for unit testing Java classes.  To test a class with JUnit: Design a companion test class that contains test cases. Each test case is a method whose name starts with test. The test class must import junit.framework.* The test class must extend TestCase

18. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 18 Example Class to Test package cs160.util; public class Calculator { public double add(double first, double second) { return first + second; // OK! } public double subtract(double first, double second) { return second - first; // oops! } public double multiply(double first, double second) { try { // slow multiplication! Thread.sleep(3000); } catch (InterruptedException ex) {} return first*second; } public double divide(double first, double second) throws IllegalArgumentException { if (second == 0.0) { // oops! return 0.0; // don ’ t divide } else { throw new IllegalArgumentException(); }

19. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 19 JUnit Integration with NetBeans  Right-click the class you want to test. Select Tools  Create/Update Tests  NetBeans creates a test directory for your project.  NetBeans generates a *Test class. * is replaced with the name of the class you want to test.

20. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 20 Run JUnit Tests  Right-click a test class and select “Test File”  NetBeans will run each test case method of the test class and display a graph showing the number of tests that succeeded and the number of tests that failed. NetBeans + JUnit demo

21. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 21 JUnit-Generated Test Methods  The method to test:  Prototype test method generated by JUnit: public double add(double first, double second) { return first + second; // OK! } import junit.framework.TestCase; public void testAdd() { System.out.println("add"); double first = 0.0; double second = 0.0; Calculator instance = new Calculator(); double expResult = 0.0; double result = instance.add(first, second); assertEquals(expResult, result, 0.0); fail("The test case is a prototype."); } You can modify each prototype test method in order to make it more useful or subclass the generated test class. JUnit demo (part 1)

22. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 22 JUnit Tests for Expected Results public void testAdd() { System.out.println("Testing: add"); double first = 2.0; double second = 3.0; Calculator instance = new Calculator(); double expResult = 5.0; double result = instance.add(first, second); assertEquals(expResult, result, 0.0); } MyCalculatorTest.java

23. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 23 JUnit Test for a Timeout import java.util.concurrent.TimeoutException; public void testMultiplyWithTimeout() throws InterruptedException, TimeoutException { System.out.println("Testing: multiply"); Thread testThread = new Thread() { public void run() { double first = 3.0; double second = 4.0; Calculator instance = new Calculator(); double expResult = 12.0; double result = instance.multiply(first, second); assertEquals(expResult, result, 0.0); } }; testThread.start(); Thread.sleep(1000); // 1 second (or some other duration) testThread.interrupt(); if (testThread.isInterrupted()) { throw new TimeoutException("The test timed out"); } } MyCalculatorTest.java

24. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 24 JUnit Test for an Expected Exception public void testDivideWithException() { System.out.println("Testing: divide"); try { double first = 5.0; double second = 0.0; Calculator instance = new Calculator(); double expResult = 0.0; double result = instance.divide(first, second); assertEquals(expResult, result, 0.0); fail("IllegalArgumentException was expected"); } catch (IllegalArgumentException ignore) {} } JUnit demo (part 2) MyCalculatorTest.java

25. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 25 JUnit API Documentation  See http://junit.sourceforge.net/javadoc/http://junit.sourceforge.net/javadoc/ Also available from within NetBeans

26. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 26 How to Test a Web Application  Hire an army of trained monkeys.  Each monkey tests the web pages by entering values into text fields, choosing menu items, clicking on links, and pressing buttons.  The more monkeys, the more thorough the testing. Student interns are almost as good!

27. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 27 How to Test a Web Application, cont’d  Automate website testing with a Java program.  The program enters values into the text fields, chooses menu items, clicks on links, and presses buttons. The server code (servlets) don’t know that it’s talking to a program.  Use the open-source tool HttpUnit Emulates browser behavior, including form submission. Download from http://httpunit.sourceforge.net/http://httpunit.sourceforge.net/

28. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak Testing with HttpUnit 28 private static final String URL = "http://localhost:8084/LegacyDemo/"; private void squareRootTest(String number) throws Exception { WebConversation conversation = new WebConversation(); WebRequest request = new GetMethodWebRequest(URL); WebResponse response = conversation.getResponse(request); WebForm form = response.getForms()[0]; form.setParameter("number", number); response = form.submit(); String text = response.getText(); System.out.println(text); } Create a conversation with the website. Get the response. Set the form's "number" input field and then submit the form. Get and print the response text. Demo RootEngineTester.java

29. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 29 Integration Testing  After your code has passed all the unit tests, you must do integration testing to see how your unit works with other units. Other units written either by you or by other developers.  Not too hard to do if you’ve been doing continuous integration all along.

30. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 30 Stress Testing  AKA load testing  How well does the application behave under stress?  Will its performance be acceptable?

31. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 31 Stress Testing, cont’d  Add a test driver that pushes your application beyond what is possible with manual testing. Input values at or just beyond their limits Large number of input values or large database tables Number of clients. Number of requests. Number of concurrent requests. Frequency of requests. Types of requests.

32. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 32 Stress Testing, cont’d  Push your application until it breaks.  Know what the breaking point is. If you don’t find out before deployment, the users will!  Understand the behavior of your application under stress. Recognize when it’s about to break so you have time to mitigate.

33. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 33 Stress Testing, cont’d  Use a multi-threaded test program and HttpUnit to simulate a large number of simultaneous users of a web application.  Measure the response time of each simulated user as the number of users increases. Demo

34. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 34 Stress Testing Example: Mars Rover Mission  Simulate multiple users performing client operations simultaneously.  Can the server handle a heavy load?

35. Computer Science Dept. Fall 2014: November 12 CS 160: Software Engineering © R. Mak 35 Regression Testing  Make a collection of unit tests.  Run all the tests whenever you make a code change. Make sure your application did not lose functionality or “regress”. Make sure a bug fix did not introduce new bugs.  Programmers are much less reluctant to improve their code if they can run regression tests to verify their changes.