Test-Driven Development

What is TDD? “Before you write code, think about what it will do. Write a test that will use the methods you haven’t even written yet.” A test is not something you “do”, it is something you “write” and run once, twice, three times, etc. It is a piece of code Testing is therefore “automated” Repeatedly executed, even after small changes

TDD Stages In Extreme Programming Explored (The Green Book), Bill Wake describes the test / code cycle: Write a single test Compile it. It shouldn’t compile because you’ve not written the implementation code Implement just enough code to get the test to compile Run the test and see it fail Implement just enough code to get the test to pass Run the test and see it pass Refactor for clarity and “once and only once” Repeat

Refactor code (and test) TDD Stages Write a test Refactor code (and test) Compile Run test, watch it pass Fix compile errors Write code Run test, watch it fail

Test-Driven Development Writing tests before code clarifies the requirements to be implemented. Requirements drive the tests. Tests drive the development of the application code 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.

from Janzen and Saiedian

from Janzen and Saiedian * * The Edwards study used novice programmers

Guideline for Test-Driven 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. 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

Guideline for Test-Driven 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 Test-Driven 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

Eclipse-Workbench Terminology Menu bar Text editor Tool bar Perspective and Fast View bar Outline view Resource Navigator view [Contains animated elements] Bookmarks view Properties view Tasks view Message area Editor Status area Stacked views

Java Perspective Java-centric view of files in Java projects Java elements meaningful for Java programmers Java project package class field method Java editor

Java Perspective Search for Java elements Declarations or references Including libraries and other projects Hits flagged in margin of editor All search results

Java Editor Method completion in Java editor List of plausible methods Doc for method [Contains animated elements]

Java Editor On-the-fly spell check catches errors early Click to see Quick fixes Preview Click to see fixes [Contains animated elements] Syntax and spell checking are done on-the-fly. Calls Java compiler to parse source code and resolve names in context. Developers refer to those wavy red lines as “the red sea” :-). Problem markers are appear in the left margin of editor. “Red X” instead of “light bulb” if no proposed corrections. Problem

Java Editor Java editor helps programmers write good Java code Variable name suggestion JavaDoc code assist [Contains animated elements] Argument hints and proposed argument names

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 assertEquals assertTrue/False assertSame/NotSame assertNull/NotNull

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 is changing the internal structure of the code without changing functionality Examples: Remove duplicate 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.

Refactoring JDT has actions for refactoring Java code

Refactoring Growing catalog of refactoring actions Organize imports Rename {field, method, class, package} Move {field, method, class} Extract method Extract local variable Inline local variable Reorder method parameters

JUnit with Eclipse

Summary (1) In TDD: Requirements drive the tests. Tests drive the development of the application code. No application code is written without writing a failing test first. Tests are collected in a suite and the suite is run frequently, like every time after code is written. Test and code are written in elementary increments. Refactoring is a continuous operation, and is supported by a passing battery of tests.

Summary (2) TDD is good because it: Reduces the number of bugs by orders of magnitude, Increases development speed, because less time is spent chasing bugs. Improves code quality because of the increased modularity, and continuous and relentless refactoring. Decreases maintenance costs because the code is easier to follow.

Our Assignment Platform: Eclipse Language: Java Techniques you will use Test-driven