1. Unit Testing & Code Coverage Please download and install EclEmma (link in resources section…I recommend Option 2) Also snarf the junit code for today’s class

2. Please be aware… There are readings posted for Thursday and Friday

3. What Are Unit Tests? Small tests that test a particular small part of your code separate from everything else Contrast with integration tests that test how large parts of the system work together

4. Why Unit Test? They let you verify your code functions properly under a variety of circumstances They protect against “regressions” – when a feature you had previously implemented breaks They improve the design of your code by encouraging you to make the various parts of the system independent from each other

5. When rules are complex, you NEED unit testing 1.Scientific computing 2.Board game 3.Any situation where you can’t eyeball results and know if they are correct

6. It is really important to decouple unit tests from other parts of the system If you tests break frequently for unrelated stuff, that’s a sign you have built you tests incorrectly

7. Generate as many different test cases as you can for…. Name Parsing e.g. (parse “Mr. Michael Hewner”). We want to parse a name string into parts. The parts we care about are: Title (i.e. "Mr") First Name (i.e. "John") Last Name (i.e. "Smith") Suffix (blank in sample case, could be Jr, II, PhD, DDS, etc) The rules of parsing are: The words have the strict order – the Title, the First Name, Last Name and the Suffix. A word can contain a hyphen. If the name contains only one word, it is treated as the Last Name. If the name contains two words and the first word is a title, the second word is treated as the Last Name. If the name contains two or more words and the first word is not a title, the first two words are treated as the First Name and the Last Name. If the word is in the title list, it is treated as the title. If not the Title remains empty.

8. There is a unit test framework for your language – use it You want your unit tests to be super easy to run – that way they will be run Ideally, you might do stuff like run them every night or run them everytime somebody checks something into source control

9. Use Junit to test the NameParser (snarfable) Implement as many good tests as you can As you find bugs (there are a lot) fix the code and rerun all your old tests Be sure to write some tests that verify the exceptions are correctly thrown when bad input is given Junit documentation: http://junit.sourceforge.net/doc/cookbook/cook book.htm http://junit.sourceforge.net/doc/cookbook/cook book.htm http://www.eclemma.org

10. Code Coverage Tools Tells you what percentage of your code is unit tested Easy, and a great way to spot check to make sure you’re not leaving some vast area untested Your goal is not to get to 100% coverage, but you should be around 95% or more if(worldMakesNoSense == true) { throw new RuntimeException(“I have no idea what’s going on”); }

11. Run Code Coverage on Your Tests You’ll need to download and install EclEmma (http://www.eclemma.org...I like installation option 2) Run code coverage on your tests If you code coverage is not at 100%, get it there Submit your code via ambient when you are done

12. GUIs It is not usually worth it to unit test GUIs directly (because they tend to change frequently due to UI issues) BUT…what that means is you want to pull all possible code out of the view and into the model so it can be unit tested

13. Unit Tests vs. Integration Tests Sweet Spot 1: Really simple “unit” tests that just test one small subsystem away from everything else Sweet Spot 2: Large tests that test everything end-to- end and verify your whole system does what it’s intended to do No mans land of bad tests that break frequently

14. Automated Testing Systems There are systems that will “monkey” through and interface and press every button or every link