Скачать презентацию Computer Science 209 Testing With JUnit Why Скачать презентацию Computer Science 209 Testing With JUnit Why

266d5507e684bac682bc01423709ab78.ppt

  • Количество слайдов: 17

Computer Science 209 Testing With JUnit Computer Science 209 Testing With JUnit

Why Test? • I don’t have time, I’ve got a deadline to meet • Why Test? • I don’t have time, I’ve got a deadline to meet • The more pressure I feel, the fewer tests I will write • Fewer tests lead to less accurate and less stable code • Less accurate and less stable code puts more pressure on me. . .

Integrate Testing and Coding • Code a little, test a little, code a little, Integrate Testing and Coding • Code a little, test a little, code a little, test a little. . . • Write test units before coding the pieces to be tested • Get immediate feedback and fix bugs as you code

Tester Programs • Test individual classes where possible, then interactions • Bottom-up approach • Tester Programs • Test individual classes where possible, then interactions • Bottom-up approach • A main method displays expected results before actual results of running methods

Testing Freecell public class Free. Cell. Tester{ public static void main(String[] args){ Free. Cell. Testing Freecell public class Free. Cell. Tester{ public static void main(String[] args){ Free. Cell. Model = new Free. Cell. Model(); System. out. println(model); } // Now what? ? } Lots of things to test! Smaller pieces (deck, cards, particular types of cells) should be tested first

Problems With Tester Programs • Must visually inspect a long output stream to check Problems With Tester Programs • Must visually inspect a long output stream to check results (tedious and error-prone) • Must create code to produce visually useful output • Tests of methods are not modularized: One long sequence that is hard to maintain

JUnit • Provides “outside influence” in the form of a framework for unit testing JUnit • Provides “outside influence” in the form of a framework for unit testing • Highly modular, can create a suite of test cases for each class and add to them incrementally • Assertion-based: A failed test halts with an error message, so verification is automated

The Basic Framework import junit. framework. *; public class Card. Test extends Test. Case{ The Basic Framework import junit. framework. *; public class Card. Test extends Test. Case{ // Will test the Card class using JUnit } Write a testing class that extends Test. Case is defined in the junit. framework package You should write a similar class for each of the classes that are unit-tested in your system

Add a Test Case import junit. framework. *; public class Card. Test extends Test. Add a Test Case import junit. framework. *; public class Card. Test extends Test. Case{ public void testget. Rank(){ Card c = new Card(2, Suit. spade); assert. True(c. get. Rank() == 2); assert. True(c. get. Rank() == 3); } } } A test case is a method that tests the functionality of another method test. Get. Rank is the test case for get. Rank assert. True expects true and halts the test if it gets false

Testing equals import junit. framework. *; public void testequals(){ Card c 1 = new Testing equals import junit. framework. *; public void testequals(){ Card c 1 = new Card(2, Suit. spade); Card c 2 = new Card(3, Suit. heart); assert. Equals(c 1, c 1); assert. Equals(c 1, new Card(2, Suit. spade)); assert. True(! c 1. equals(c 2)); } } assert. Equals runs the equals method with its two parameters Be sure to test all of the possible options of equality

Establish a Fixture import junit. framework. *; public class Card. Test extends Test. Case{ Establish a Fixture import junit. framework. *; public class Card. Test extends Test. Case{ private Card c 1, c 2; protected void set. Up(){ c 1 = new Card(12, Suit. spade); c 2 = new Card(12, Suit. heart); } } // Tests for get. Rank and equals can use c 1 and c 2 A fixture captures a common context for several test cases This context consists of a set of objects that can be initialized once in a setup method and made visible to all test cases Some fixtures can consist of many objects, so this really saves time

Create a Suite of Test Cases import junit. framework. *; public class Card. Test Create a Suite of Test Cases import junit. framework. *; public class Card. Test extends Test. Case{ // Code for fixture and test cases public Card. Test(String s){ super(s); } public static Test suite(){ Test. Suite suite = new Test. Suite(); suite. add. Test(new Card. Test("testget. Rank")); suite. add. Test(new Card. Test("testequals")); return suite; } public static void main(String[] args){ junit. textui. Test. Runner. run(suite()); } } Be sure that the names of the test case methods are spelled correctly! Create an instance of Card. Test for each test case method and pass the name of the method to the constructor Add each case to a Test. Suite object Run the suite in the main method

Create a Suite of Test Cases import junit. framework. *; public class Card. Test Create a Suite of Test Cases import junit. framework. *; public class Card. Test extends Test. Case{ // Code for fixture and test cases public Card. Test(String s){ super(s); } public static Test suite(){ Test. Suite suite = new Test. Suite(Card. Test. class); return suite; } public static void main(String[] args){ junit. textui. Test. Runner. run(suite()); } } Alternatively, pass the class of the test cases to another Suite constructor Create an instance of Card. Test for each test case method and pass the name of the method to the constructor Add each case to a Test. Suite object Run the suite in the main method

Running a Test For a simple batch-style text interface: >java Patron. Test For a Running a Test For a simple batch-style text interface: >java Patron. Test For a GUI that allows you to track and run tests for multiple classes: >java junit. swingui. Test. Runner

Guidelines for Testing • Write tests as you develop, when you imagine how the Guidelines for Testing • Write tests as you develop, when you imagine how the code will run • Factor the test code to reflect the factoring of your system • Keep the old tests running, and always run all of your tests

Guidelines for Testing • Avoid writing print statements; write tests instead • Focus on Guidelines for Testing • Avoid writing print statements; write tests instead • Focus on tests that are useful – When you add functionality to the system – During debugging, write a test that will succeed if the code works, then debug with it

Guidelines for Testing • Run every test at least once a day • Set Guidelines for Testing • Run every test at least once a day • Set them up so that you can’t go home unless they’re all 100% • You’ll be more aggressive about refactoring because you won’t fear breaking the code