cs 160: software engineering november 12 class meeting department of computer science san jose state...
TRANSCRIPT
CS 160: Software EngineeringNovember 12 Class Meeting
Department of Computer ScienceSan Jose State University
Fall 2014Instructor: Ron Mak
www.cs.sjsu.edu/~mak
Computer Science Dept.Fall 2014: November 12
CS 160: Software Engineering© R. Mak
2
Tesla Headquarters VisitBourne Joseph student Computer EngineeringCaires Debra professor Computer ScienceDhillon Gurleen student Computer EngineeringDimov Dima student Computer ScienceEstell Khalil student Computer EngineeringFlores Pedro student Computer ScienceGallegos Kevin student Computer EngineeringInzunza Oscar student Computer ScienceJoshi Hardik student Computer ScienceKang Jack student Computer ScienceKannan Prakasam student Computer ScienceKoumis Alex student Computer EngineeringLong Camille student Computer EngineeringMak Ron professor Computer ScienceNarahari Srikanth student Computer ScienceNguyen Duy student Computer EngineeringPatel Jay student Computer ScienceShah Shukan student Computer ScienceThorpe David student Computer ScienceTorrefrancaDaniel student Computer EngineeringTran Duc student Computer EngineeringTran Hung student Computer EngineeringTsui Helen student Computer EngineeringWei Eileen student Computer ScienceWong Nelson student Computer Engineering
Friday, November 14 at 2:00
3500 Deer Creek RoadPalo Alto
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Computer Science Dept.Fall 2014: November 12
CS 160: Software Engineering© R. Mak
15
Unit Testing: Testing Framework
UNIT(What’s
being tested)
TESTDRIVER
calls TESTSTUB
calls
TESTSTUB
calls
TESTSTUB
calls
Computer Science Dept.Fall 2014: November 12
CS 160: Software Engineering© R. Mak
16
Writing and Running Unit Tests
Developers are responsible for writingunit 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.
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
Computer Science Dept.Fall 2014: November 12
CS 160: Software Engineering© R. Mak
18
Example Class to Testpackage 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(); } }}
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.
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
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 eachprototype test method
in order to make it more usefulor subclass the generated test class.
JUnit demo(part 1)
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
Computer Science Dept.Fall 2014: November 12
CS 160: Software Engineering© R. Mak
23
JUnit Test for a Timeoutimport 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
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
Computer Science Dept.Fall 2014: November 12
CS 160: Software Engineering© R. Mak
25
JUnit API Documentation
See http://junit.sourceforge.net/javadoc/ Also available from within NetBeans
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!
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/
Computer Science Dept.Fall 2014: November 12
CS 160: Software Engineering© R. Mak
28
Testing with HttpUnit
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 theresponse text.
Demo
RootEngineTester.java
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.
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?
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.
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.
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
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?
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.