CS 160: Software Engineering November 12 Class Meeting Department of Computer Science San Jose State University Fall 2014 Instructor: Ron Mak mak

CS 160: Software EngineeringNovember 12 Class Meeting

Department of Computer ScienceSan Jose State University

Fall 2014Instructor: Ron Mak

www.cs.sjsu.edu/~mak

http://www.cs.sjsu.edu/~mak

http://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



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

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

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

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

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

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

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

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

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

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

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

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

Unit Testing: Testing Framework

UNIT(What’s

being tested)

TESTDRIVER

calls TESTSTUB

calls

TESTSTUB

calls

TESTSTUB

calls



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.



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

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



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

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

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)



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

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




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)




25

JUnit API Documentation

See http://junit.sourceforge.net/javadoc/ Also available from within NetBeans

http://junit.sourceforge.net/javadoc/



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

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

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



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

Stress Testing

AKA load testing

How well does the application behave under stress?

Will its performance be acceptable?



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


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


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

Stress Testing Example: Mars Rover Mission

Simulate multiple users performing client operations simultaneously.

Can the server handle a heavy load?



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.

Documents

CS 160: Software Engineering November 12 Class Meeting Department of Computer Science San Jose State University Fall 2014 Instructor: Ron Mak mak