Class Notes (810,429)
Canada (494,121)
CSC207H1 (40)


6 Pages
Unlock Document

University of Toronto St. George
Computer Science
Diane Horton

OCTOBER 24  Test-driven development o Write you tests first  In the real world this is ideal  The tests are based on requriements rather than code  The tests determine the code you need to write  There is no code unless there is a test that requires it in order to pass  Unit testing o Also called component testing o The goal is to fully test a class in isolation o For example:  Getting and setting all attributes  Calling all methods with a simple parameter o Ultimately, the aim is to exercise the object in all possible states  System testing o Also called integration testing o The goal is to verify that components interact appropriately o For CSC207H, this usually involves the whole program o For larger systems this may involve sub-components of the system  Regression Testing o Regression occurs when something that used to work stops working o Regression testing is testing that is done to prevent regression o A set of tests are maintained in parallel with the system (both unit and system tests) o Before committing any change to the system, the tests are run to verify that all components continue to work o Whenever a new feature is added, new regression test that specify how the feature should work are added  Testing Terminology o Test or test case: An action carried out o Fixture: The context of the test (e.g. a data structure with a set of values)  In the simplest Java case, a single initialized object one of whose methods is to be called. o Possible results:  pass: test produced the expected outcome  fail: test ran but produced an incorrect outcome  error: test failed to produce an answer: there is something wrong with the test itself  Unit Testing o Unit testing follows a pattern  Lots of small, independent tests  Reporting passes, failures, and error  Some optional setup and teardown shared across tests  Aggregation (combine tests into test suites) o We could accomplish all of this “by hand” but these design principles inspired by JUnit  When you see a pattern, build a framework  Write shared code once  Make it easy for people to do things the right way o JUnit – standard for testing java software  JUnit uses reflection to look up methods  (Reflection: extracting characteristics of a class or method at run time.)  Pass in the class (!) containing your tests  JUnit decides which methods to run based on their annotations (An annotation is syntactically like a type.)  If a method is annotated with “@Test”, TestRunner will execute it  Setup and Teardown  There are three steps in running a test: setup, run, and teardown  The setup phase is in a (single) method annotated with @Before  The teardown phase is in a single method annotated with @After  These run before and after every test case  The methods annotated with @BeforeClass and @AfterClass run once overall  In setup and teardown, you can create data structures required by multiple tests or clean up after tests  Testing for Exceptions  How do you test a case that is supposed to fail by throwing an exception?  @Test annotation takes an optional parameter. 1. @Test(expected = NumberFormatException.class) 2. public void testFromString() { 3. int x = Integer.parseInt("m") + 3; 4. } OCTOBER 24  Selecting Test Cases o Test for success  General cases, well-formatted input, boundary cases  Classics: 0, 1, more; odd, even; beginning, “middle”, end o Test for failure  Invalid input  Does it throw the exceptions it is supposed to? o Test for “sanity”  Check data structure consistency  Consider writing comments (representation invariants) that state what constitutes consistent  Design for Testability o When you are writing code, think about what you need to test and how you can test it.  Always write toString() methods o Write methods that do a single thing o Separate input, computation, and output when possible o Modularity, modularity, modularity.  Don’t delay writing tests! Write tests before you write code as part of the requirements stage and update those tests as or after you write code.  Picking a Visibility o Choose Java member visibilities carefully o Public and protected are both effectively public o private is untestable o "package private" (default) can be very helpful  Testing queue o 1. package testingDemos; 2. public class QueueEmptyException extends Exception { 3. } o 1. package testingDemos; 2. 3. public class Queue { 4. private int maxSize; // The max capacity of this Queue. 5. private int size; // The actual number of items in this Queue. 6. Object[] contents; // The contents of the Queue. 7. int front; // The index of the front item. 8. int end; // The index after the last item in the queue. 9. 10. // Representation invariant: 11. // 0 <= front < contents.length && 0 <= end < contents.length 12. // if size == 0, then no items in the queue, and the next item will be inserted at index end. 13. // if size == contents.length, the array is full and front == end. 14. // Otherwise: 15. // if front < end: 16. // the queue is in contents[front..end - 1] 17. // If end < front: 18. // the queue is in contents[front..] followed by contents[..end - 1] 19. 20. // A new Queue with size 0 and initial capacity c. 21. // @param c the initial maximum capacity. 22. public Queue(final int c) { 23. maxSize = c; 24. contents = new Object[maxSize]; 25. } 26. 27. // Add o to the end of me. 28. // @param o the object to add. 29. public final void enqueue(final Object o) { 30. if (size < maxSize) { 31. // there's room. 32. contents[end] = o; 33. end = (end + 1) % contents.length; 34. size++; 35. } else { 36. // make a bigger array and copy the contents over. 37. } 38. } OCTOBER 24 39. // Remove and return the front object. 40. // @return the front object. Or if the queue is empty, throw an QueueEmptyException. 41. public Object dequeue() throws QueueEmptyException { 42. if (size == 0) { 43. // throw new QueueEmptyException(); 44. return null; 45. } else { 46. size -= 1; 47.
More Less

Related notes for CSC207H1

Log In


Don't have an account?

Join OneClass

Access over 10 million pages of study
documents for 1.3 million courses.

Sign up

Join to view


By registering, I agree to the Terms and Privacy Policies
Already have an account?
Just a few more details

So we can recommend you notes for your school.

Reset Password

Please enter below the email address you registered with and we will send you a link to reset your password.

Add your courses

Get notes from the top students in your class.