Test-first development Writing tests before code clarifies the requirements to be implemented. Tests are written as programs rather than data so that they can be executed automatically. The test includes a check that it has executed correctly. All previous and new tests are automatically run when new functionality is added. Thus checking that the new functionality has not introduced errors.

Guideline for Testing first The name of the test should describe the requirement of the code There should be at least one test for each requirement of the code. Each possible path through of the code is a different requirement Only write the simplest possible code to get the test to pass, if you know this code to be incomplete, write another test that demonstrates what else the code needs to do A test should be similar to sample code, in that it should be clear to someone unfamiliar with the code as to how the code is intended to be used

Guideline for Testing first If a test seems too large, see if you can break it down into smaller tests If you seem to be writing a lot of code for one little test, see if there are other related tests you could write first, that would not require as much code Test the goal of the code, not the implementation One test/code/simplify cycle at a time. Do not write a bunch of tests, and try to get them working all at once Keep writing tests that could show if your code is broken, until you run out of things that could possibly break

Guideline for Testing first When choosing an implementation, be sure to choose the simplest implementation that could possibly work If you are unsure about a piece of code, add a test you think might break it A test is one specific case, for which there is a known answer If all of the tests succeed, but the program doesn't work, add a test

JUnit with Eclipse Before writing any code fragment, an automated test must be written to check the functioning of this code. Since the code does not exist yet, it initially fails the test. After the test begins to pass, duplicate code must be removed.

JUnit with Eclipse Run Eclipse IDE. We will create a new workplace project so click File -> New -> Project, then choose Java and click Next. Type in a project name -- for example, ProjectWithJUnit. Click Finish. The new project will be generated in your IDE. Let's configure our Eclipse IDE, so it will add the JUnit library to the build path. Click on Project -> Properties, select Java Build Path, Libraries, click Add External JARs and browse to directory where your JUnit is stored. Pick junit.jar and click Open. You will see that JUnit will appear on your screen in the list of libraries. By clicking Okay you will force Eclipse to rebuild all build paths.

JUnit with Eclipse To create such a test, right-click on the ProjectWithJUnit title, select New -> Other, expand the "Java" selection, and choose JUnit. On the right column of the dialog, choose Test Case, then click Next.

JUnit with Eclipse import junit.framework.TestCase; public class TestThatWeGetHelloWorldPrompt extends TestCase { public TestThatWeGetHelloWorldPrompt( String name) { super(name); } public void testSay() { HelloWorld hi = new HelloWorld(); assertEquals("Hello World!", hi.say()); public static void main(String[] args) { junit.textui.TestRunner.run( TestThatWeGetHelloWorldPrompt.class);

JUnit with Eclipse public class HelloWorld { public String say() { return("Hello World!"); } } How to write a test case? Set up preconditions Exercise functionality being tested Check postconditions

JUnit with Eclipse Failure test successful test

JUnit with Eclipse The framework uses reflection to find and collect all of the test methods whose signature match Public void testWhatever () We cannot control the order in which the test methods will be run

JUnit with Eclipse

Refactoring Refactoring Refactoring is changing the internal structure of the code without changing functionality Examples: Remove duplicate code Leverage existing code Remove unused code Refactoring mercilessly requires good unit tests and functional tests that can easily be executed Refactoring: If you are adding functionality – you are not refactoring! Although you may need to refactor before adding funtionality. Metaphor example: Pub/Sub system has Publishers Subscribers Topics Messages Does not need to be overly abstracted.

JUnit with Eclipse

Our Assignment Platform: Eclipse Language: Java Screen recording: Microsoft Producer Techniques you will use Test-driving think-aloud

References Kent Beck: „Extreme Programming Explained – Embrace Change“ Martin Fowler: „Refactoring“ XP Exchange www.xpexchange.net Don Wells www.extremeprogramming.org Ron Jeffries www.xprogramming.com There are more in the XP Series by Addison-Wesley; this is just for a start. See also any of the web-sites mentioned.