CPSC 330 Software Engineering

Size: px

Start display at page:

Download "CPSC 330 Software Engineering"

Franklin Byrd
8 years ago
Views:

1 CPSC 330 Software Engineering Lecture 4: Unit ing, JUnit, and Software Development Processes Today Unit ing and JUnit Software Development Processes (as time allows) Reading Assignment Lifecycle handout Ch 7: pp Podcast: Kent Beck on JUnit (opt) Assignments HW 1 due HW 2 assigned 2 1

2 3 Basic ing Concepts Verification and Validation Verification Does the software satisfy the specification? Is it built right? Validation Does the software fulfill its intended purpose? Was the right thing built? 4 2

3 Basic ing Concepts A failure A situation where the behavior of the software as it executes deviates from what is expected A defect (aka bug) The cause of a failure Some part of the code that is incorrectly implemented 5 Basic ing Concepts ing has two components Finding defects (bugs) Fixing defects As developers and testers We want to find defects in the system So we can fix them And ensure (verify) our system is working correctly Unfortunately All software has bugs 6 3

4 Basic ing Concepts Why do we care about testing? Software Reliability The probability of failure-free operation in a specified environment for a specified time Often reliability is tied to some level of failure-freeness (i.e., some failures may be fine) Reliability is an (important) aspect of quality Others: is it usable, efficient, maintainable, complete, welldocumented, We can help ensure reliability through testing 7 Basic ing Concepts Different aspects of a system are tested Component Code Unit ed Components Design Specifica@on Func@onal Requirements Non- Func@onal Requirements (characteris@cs) Customer User Environment Component Code Unit Integra@on Func@on Performance Acceptance Installa'on * Component Code Unit Lots and lots of tests!... Need to keep track of all this data Fix Errors and Regression Rerun tests to make sure other parts are not affected by changes 8 4

5 Basic ing Concepts A slightly different terminology (view) White (open) Box Tes@ng Gray Box Tes@ng Black (closed) Box Tes@ng Look inside the system Code, DBs, algorithms, etc. E.g., test all paths through code (not prac@cal!) s based on how system designed and coded (mainly unit tests) Mainly outside peek under the hood a bit E.g., test DBs, network connec@ons, mem/disk usage (performance tests) Do not look inside system inputs and outputs What the user sees (func'onal & acceptance tests) 9 Regression ing A common pattern Write some (often small) portion of the application Define test cases and get them to pass (succeed) Modify the code (i.e., refactor and/or extend) How do we ensure the changes didn t mess up previous code? By performing regression testing Rerun our tests to ensure they still pass Helps ensure changes didn t introduce bugs in our previous work 10 5

6 Unit s (white box) individual components (or units ) of the code For example, a method or class could each be a unit What constitutes a unit is somewhat open-ended each unit in isolation For example, each method of a class is tested individually Again, isolation is somewhat open-ended Historically starts by analyzing code Then determine the proper test cases New approaches do things differently (test-driven design) 11 Unit s (white box) The nature of test cases can vary Often just giving inputs to check outputs But depends on the unit under test For example, for a method could be Whether it succeeds for normal use Whether it handles abnormal use (like throws Exceptions) Whether it calls other methods properly 12 6

7 Automated ing In automated testing Sets of test cases (test suites) are executed and verified by a computer program This is in contrast to manual testing where you have to execute and verify the test cases by hand Automated tests are written as code Requires writing test code to verify program behavior Can lead to lots of additional code (for testing) And this code is not part of the production code 13 Pros and Cons of Automated s Disadvantages over manual tests Slower to develop because involves writing code Can be tricky to write for some cases (e.g., GUIs) Advantages over manual tests Much easier to do regression testing Can be executed quickly The computer doesn t get bored s are run the same way each time The code serves to document the test Code without automated tests is often viewed as highly suspect! 14 7

8 Automated ing Frameworks There are lots of tools for automated testing We re going to look at JUnit 4 A widely used Unit ing framework Download at: Tools like JUnit try to make it as painless as possible (to write and run unit tests) Most of these tools are very similar E.g., NUnit (.Net), CppUnit (C++), PyUnit (Python), 15 Lets say we have this (really) simple class public class Stock { private int shares; private String symbol; public Stock(int theshares, String thesymbol) { shares = theshares; symbol = thesymbol; public int calculatevalue(int shareprice) { return shareprice * shares; public void sell(int amount) { shares = shares amount; 16 8

9 What are some test cases for the Stock class? Make sure it calculates the correct value Make sure a sell is recorded correctly Lets write tests for these: Create 10 shares of ORCL The value of the stock at $30/share should be $300 Create 10 shares of ORCL After selling 5 shares, the value at $30/share should be $150 Create 5 shares of ORCL After selling 10 shares, the value at $30/share should be $0 17 Before we get started We need to download the JUnit jar file (java archive) I m using junit jar For now, put the jar in the same directory as Stock.java We need the jar file to run our tests All of our tests are going to go into a testing class I m calling this Stock 18 9

10 Lets start with the first test Each test is placed in a separate method in the test class import org.junit.*; import static org.junit.assert.*; public class Stock public void shouldgive300dollarsfor10shares() { Stock stock = new Stock(10, ORCL ); asserttrue(stock.calculatevalue(30) == 300); 19 To compile, we need to include the jar file javac -cp.:junit jar *.java On windows, you would use ; instead of : To run our tests we use the JUnitCore class $ java -cp.:junit jar org.junit.runner.junitcore Stock Unit version Time: This means we ran one test and it passed! OK (1 test) 20 10

11 Lets add our second test Again, each test is a method in the test class import org.junit.*; import static org.junit.assert.*; public class Stock public void shouldgive300dollarsfor10shares() public void shouldgive150dollarsafterselling5shares() { Stock stock = new Stock(10, ORCL ); stock.sell(5); asserttrue(stock.calculatevalue(30) == 150); 21 To compile, we again need to include the jar file javac -cp.:junit jar *.java And to run our tests we use the JUnitCore class $ java -cp.:junit jar org.junit.runner.junitcore Stock Unit version Time: This means we ran two tests and they passed! OK (2 tests) 22 11

12 And finally, our third test import org.junit.*; import static org.junit.assert.*; public class Stock public void shouldgive300dollarsfor10shares() public void shouldgive150dollarsafterselling5shares() public void shouldgive0dollarsaftersellingover5shares() { Stock stock = new Stock(5, ORCL ); stock.sell(10); asserttrue(stock.calculatevalue(30) == 0); 23 Again, recompile and run $ java -cp.:junit jar org.junit.runner.junitcore Stock Unit version E Time: There was 1 failure: 1) shouldgive0dollarsaftersellingover5shares(stock) java.lang.assertionerror:... exception message here... FAILURES!!! s run: 3, Failures: 1 This means we ran three tests, two passed, one failed! 24 12

Fail early, fail often, succeed sooner!

Fail early, fail often, succeed sooner! Contents Beyond testing Testing levels Testing techniques TDD = fail early Automate testing = fail often Tools for testing Acceptance tests Quality Erja Nikunen