1. Test-Driven Development

2. 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

3. 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

4. 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

5. 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.

6. from Janzen and Saiedian

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

8. 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

9. 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

10. 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

11. 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

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

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

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

15. 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

16. 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

17. 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.

18. 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.

19. 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);

20. 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

21. JUnit with Eclipse
Failure test successful test

22. 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

23. JUnit with Eclipse

24. 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.

25. Refactoring
JDT has actions for refactoring Java code

26. 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

27. JUnit with Eclipse

28. 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.

29. 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.

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