CSC323 2010S, Class 10: Unit Testing Overview: * Project Discussion. * About Unit Testing and Test-Driven Development. * Beautiful Testing. * PyUnit: Unit Testing in Python. * Lab: Unit Testing. Admin: * For Tuesday: Choose a fun model for iSimGrinL * Maybe express as use cases. * Readings for Tuesday Skim Chapters 1 and 2 of Version Control with Subversion (for Subversion 1.5); Read BC 2: Subversion's Delta Editor. * At times, I felt like I read something different than the rest of you. * So sad. Escher is gone. It's because of STUDENTS! * EC: Today's CS Extra. * EC: Tomorrow's CS Table. Project Ideas: * No, we are not doing an MP3 database. * No, we are not doing "nevermind I forgot" Project Decision: Networked, Competitive/Cooperative, Sim game * What will be the primary creatures in the system? * Viruses? No * Fish? No * Bugs? Maybe * Grinnellians? Professors, Students, Staff, Townies, Squirrels * Has some fun with subclassing and interfaces and ... * What does networked mean? * Direct competition? * Multiple copies of creatures that propagate from system to system. * A central world that clients connect to? * What is the goal of the game? Unit Testing and Test-Driven Development * Testing should be at the center of your software development process, not an afterthought * Unit testing: Testing a function against a variety of inputs to make sure that you get what you expect it to do (and that it fails when you expect it to fail) Why write tests? * Gives you some confidence that your program works. * If you do unit testing on every unit, you have confidence that all the parts of your program work individually. * The book claims that tests can help you think more carefully about your code and may even encourage you to rewrite it. * Test PERMIT you to rewrite your code. * Tests document expectations. * Good tests permit automatic testing. Why write tests first? * Helps you think more carefully about the requirements of the program. * Writing tests later can bias you about the tests. * Write code to meet tests rather than tests to meet code. * Evidence suggests "I'll do it later" becomes "later than release". To test well, we need * Methodology that uses testing (e.g., test-driven development, most of the agile methodologies) * Methodology for writing good tests * Framework that makes it easier to write and run test suites The standard framework * Build test cases * Tie them together into a hierarchy of test suites Simple test case: Explore fractions * Build the fractions 1/2, 1/3, 1/6, and 5/6 * Verify 1/2 * 1/3 = 1/6 * Verify 1/3 * 1/2 = 1/6 * Verify 1/6 / 1/2 = 1/3 * Verify 1/2 + 1/3 = 5/6 * Verify 5/6 - 1/2 = 1/3 * Etc. Before running tests, you often need to build some values Test case: * Build data * Run tests * Clean up data --- * Sam goes over questions from students * Can we generate a random sorted array of size N faster than in O(N) steps? * Start with some number (negative or positive, random) * Repeatedly add a random non-negative number to the previous number to generate the next number * Problem: Might go over MAX_VALUE * Choose a smaller range for the next value. values[i] = random(MAX_VALUE - values[i-1]) * Doesn't work if values[i-1] is negative. * Clever tricks will help * Not really a random distribution, but probably close enough. Is testing beautiful? * Beautiful parts * Our author thinks that random testing is beautiful for sniffing out problems * Testing is beautiful, it's like a painter stepping back from a canvas * Good testing helps you work in situations you can't imagine * Ugly parts * Random testing seems much less nice than systematic testing * O(nlogn) per random test. * Most programmers don't write comprehensive tests * Lessons * JUnit is simple enough that we should use it all the time and teach it in 207. * Try to write comprehensive tests (but be careful with your time) Questions * Write a simple set of unit tests for a subset of Python's numeric operations. * How might you check whether sqrt is appropriate? * Write a test suite for the sort operation.