CPSC 330 Software Engineering

Full text

(1)1/20/11 . CPSC 330 Software Engineering Lecture 4: . Unit Testing, JUnit, and. Software Development Processes. Today … • Unit Testing and JUnit. • Software Development Processes (as time allows). • Reading Assignment. – Lifecycle handout. – Ch 7: pp. 235-251. – Podcast: Kent Beck on JUnit (opt). • Assignments. – HW 1 due. – HW 2 assigned. CPSC 330 -‐-‐ Spring 2011 . 2 . 1 .

(2) 1/20/11 . CPSC 330 -‐-‐ Spring 2011 . 3 . Basic Testing 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?”. CPSC 330 -‐-‐ Spring 2011 . 4 . 2 .

(3) 1/20/11 . Basic Testing 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. CPSC 330 -‐-‐ Spring 2011 . 5 . Basic Testing Concepts • “Testing” 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 … . CPSC 330 -‐-‐ Spring 2011 . 6 . 3 .

(4) 1/20/11 . Basic Testing 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. CPSC 330 -‐-‐ Spring 2011 . 7 . Basic Testing Concepts • Different aspects of a system are tested. Component Code . Unit Test . … Component Code . Non-‐Func@onal Requirements (characteris@cs) . Customer . User Environment . Func@on Test . Performance Test . Acceptance Test . Installa'on Test* . d s ste nt Te one p m. Unit Test . Func@onal Requirements . Co. Component Code . Design Speciﬁca@on . Integra@on Test . Unit Test . Lots and lots of tests! ... Need to keep track of all this data. Fix Errors and Regression Test . Rerun tests to make sure other parts are not affected by changes CPSC 330 -‐-‐ Spring 2011 . 8 . 4 .

(5) 1/20/11 . Basic Testing Concepts • A slightly different terminology (view). White (open) Box Tes@ng . Gray Box Tes@ng . Black (closed) Box Tes@ng . • Look inside the system . • Mainly outside … peek under the hood a bit . • Do not look inside system . • Code, DBs, algorithms, etc. • E.g., test all paths through code (not prac@cal!) . • E.g., test DBs, network connec@ons, mem/disk usage . • Tests based on how system designed and coded . (performance tests) . • Test inputs and outputs • What the user “sees” (func'onal & acceptance tests) . (mainly unit tests) CPSC 330 -‐-‐ Spring 2011 . 9 . Regression Testing 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. CPSC 330 -‐-‐ Spring 2011 . 10 . 5 .

(6) 1/20/11 . Unit Tests (white box) Test 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. Test 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). CPSC 330 -‐-‐ Spring 2011 . 11 . Unit Tests (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. CPSC 330 -‐-‐ Spring 2011 . 12 . 6 .

(7) 1/20/11 . Automated Testing • 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”. CPSC 330 -‐-‐ Spring 2011 . 13 . Pros and Cons of Automated Tests 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 . – Tests are run the same way each time. – The code serves to document the test. Code without automated tests is often viewed as highly suspect!. CPSC 330 -‐-‐ Spring 2011 . 14 . 7 .

(8) 1/20/11 . Automated Testing Frameworks There are lots of tools for automated testing …. – We’re going to look at JUnit 4. – A widely used Unit Testing framework. – Download at: http://www.junit.org. 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), …. CPSC 330 -‐-‐ Spring 2011 . 15 . JUnit Example 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; } } CPSC 330 -‐-‐ Spring 2011 . 16 . 8 .

(9) 1/20/11 . JUnit Example 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 . CPSC 330 -‐-‐ Spring 2011 . 17 . JUnit Example Before we get started … . We need to download the JUnit jar file (java archive). – I’m using junit-4.8.2.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 StockTest. CPSC 330 -‐-‐ Spring 2011 . 18 . 9 .

(10) 1/20/11 . JUnit Example 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 StockTest { @Test public void shouldGive300DollarsFor10Shares() { Stock stock = new Stock(10, “ORCL”); assertTrue(stock.calculateValue(30) == 300); } }. CPSC 330 -‐-‐ Spring 2011 . 19 . JUnit Example To compile, we need to include the jar file. javac -cp .:junit-4.8.2.jar *.java – On windows, you would use ‘;’ instead of ‘:’. To run our tests we use the JUnitCore class … . $ java -cp .:junit-4.8.2.jar org.junit.runner.JUnitCore StockTest Unit version 4.8.2 . Time: 0.005. This means we ran one test and it passed!. OK (1 test) CPSC 330 -‐-‐ Spring 2011 . 20 . 10 .

(11) 1/20/11 . JUnit Example 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 StockTest { @Test public void shouldGive300DollarsFor10Shares() { ... } @Test public void shouldGive150DollarsAfterSelling5Shares() { Stock stock = new Stock(10, “ORCL”); stock.sell(5); assertTrue(stock.calculateValue(30) == 150); } } CPSC 330 -‐-‐ Spring 2011 . 21 . JUnit Example To compile, we again need to include the jar file. javac -cp .:junit-4.8.2.jar *.java. And to run our tests we use the JUnitCore class … . $ java -cp .:junit-4.8.2.jar org.junit.runner.JUnitCore StockTest Unit version 4.8.2 .. Time: 0.005. This means we ran two tests and they passed!. OK (2 tests) CPSC 330 -‐-‐ Spring 2011 . 22 . 11 .

(12) 1/20/11 . JUnit Example And finally, our third test. import org.junit.*; import static org.junit.Assert.*; public class StockTest { @Test public void shouldGive300DollarsFor10Shares() { ... } @Test public void shouldGive150DollarsAfterSelling5Shares() { ... } @Test public void shouldGive0DollarsAfterSellingOver5Shares() { Stock stock = new Stock(5, “ORCL”); stock.sell(10); assertTrue(stock.calculateValue(30) == 0); } } CPSC 330 -‐-‐ Spring 2011 . 23 . JUnit Example Again, recompile and run …. $ java -cp .:junit-4.8.2.jar org.junit.runner.JUnitCore StockTest Unit version 4.8.2 This means we ran three ..E tests, two passed, one failed! Time: 0.007 There was 1 failure: 1) shouldGive0DollarsAfterSellingOver5Shares(StockTest) java.lang.AssertionError: ... exception message here ... FAILURES!!! Tests run: 3, Failures: 1 CPSC 330 -‐-‐ Spring 2011 . 24 . 12 .

(13)

No results found