1. 1-1 1) Software Development 2) with TDD at the end By Rick Mercer with help from these sources: Rational Unified Process Computing Fundamentals with C++, Rick Mercer Designing Object Oriented Software, Rebbeca Wirfs-Brock, Wilkerson, Wiener Object-Oriented Design Heuristics, Arthur Riel

2. 1-2 Software Challenges  Specification may be incomplete  Software product is expected to be used for for a long time  Ever more complex systems, high expectations  Requirements change  We don't know what the customer wants  The customers don't know what they want

3. 1-3 One Approach: Waterfall  Software go through several stages called the life cycle  Waterfall model: popular way to organize activities

4. 1-4 Waterfall Model

5. 1-5 Waterfall Model (con.)  Waterfall has some severe problems. — The team has to be almost clairvoyant little room for error — places the high risk and difficult elements towards the end  Craig Larman's book[1] provides proof that waterfall has proved to be a terrible way to develop software.[1] — In one study, 87% of all projects failed — The waterfall process was the "single largest contributing factor for failure, being cited in 82% of the projects as the number one problem." Rick will now attempt to tell a joke [1] Agile and Iterative Development: a Manager's Guide, Addison-Wesley Professional, 2003 [1]

6. 1-6 Iterative Software Development  An iteration deals with a small part of the system

7. 1-7 Rational Unified Process  Practices of RUP — Develop iteratively — Manage changing requirements — Use components such as Java classes — Visually Model with UML — Continuously test  RUP allows you to select from many processes http://www-306.ibm.com/software/awdtools/rup/

8. 1-8 A Process we'll use  Agile Manifesto See http://agilemanifesto.org/http://agilemanifesto.org/  Started with Scrum and XP, around 1995  Teams often choose from a set of practices  Use these Agile practices for the next project — Planning game: stories and estimation — Test Driven Development (TDD) — Short Releases — Sustainable Pace (two iterations) — Coding Style (use default preferences)

9. 1-9 Analysis Tools we'll use or are in this ppt file  Nouns (objects) Verbs (operations)  Scenarios — what happens when…  Role Play — team members become objects and do scenarios  Candidate Object / Responsibility / Collaborator (CRC) cards — document candidate objects, assign responsibilities, consider associations between objects

10. 1-10 Design Tool #1 we'll use Responsibility Driven Design 1. Identify candidate objects that model a system as a sensible set of abstractions 2. Determine the responsibility of each object — what an instance of the class must be able to do, — and what each instance must know about itself less important at first 3. Understand the system through role play — To help complete its responsibility, an object often needs help from other objects

11. 1-11 Design Tool #2 we'll use Test Driven Development  TDD turns traditional development around — Write test code before the methods — Do so in very small steps — Refuse to add any code until a test exists for it  You can run the test anytime — And you should do so quite often  Design consists of writing the class, the methods, and the code

12. 1-12 By Rick Mercer with help from Kent Beck and Scott Ambler Test Driven Development

13. 1-13  What is TDD?  Tests as documentation  Tests as a way to verify your code works Outline

14. 1-14 Test Driven Development (TDD) "TDD is emerging as one of the most successful developer productivity enhancing techniques to be recently discovered. The three-step: write test, write code, refactor – is a dance many of us are enjoying" — Eric Vautier, David Vydra "TDD is the Gem of Extreme Programming" — Kent Beck

15. 1-15 TDD: What is it?  TDD turns traditional development around — Write test code before the methods — Do so in very small steps — Refuse to add any code until a test exists for it Have a failing test (red bar) before writing the code to make the test pass  You can run tests anytime — And you should do so quite often

16. 1-16 Simple, yet hard to do  When you first try TDD, it requires great discipline because it is easy to “slip” and write methods without first writing a new test

17. 1-17 Comments, Documentation?  Most programmers don’t read documentation — instead they prefer to work with the code.  Programmers often look for sample code that sends messages to instances of a class — Well-written unit tests can provide such a working specification of your code more docs are necessary — Unit tests effectively become a significant portion of your technical documentation

18. 1-18 Testing Framework  An underlying assumption of TDD is that you have a unit-testing framework  Agile software developers often use the xUnit family of open source tools, such or JUnit  Without a unit-testing framework, TDD is virtually impossible.

19. 1-19 TDD Helps Design  TDD makes you think about what you want or need before you write the code — pick class and method names — decide the needed arguments — choose return types — write the class, constructors, instance variables, and methods to make what you want work

20. 1-20 Benefits of TDD  Benefits include — Rapid feedback — Have the interface (method name) before the algorithm — Know when you’re finished — Encapsulate learning — Change your code with confidence

21. 1-21 Principles of TDD  You maintain an exhaustive suite of Programmer Tests  No code goes into production unless it has  associated tests  You write the tests first  The tests determine what code you need to write

22. 1-22 Write a test plan first  Consider what needs to be tested in general  Derive specific examples — in a natural language like English rather than a formal language like Java  Think of easy cases  Think of hard cases  Try to think of crazy cases

23. 1-23 Put it all together with an Example  An Example: Five Card Draw  Using a spec Rick has not seen before — Find the objects — Assign responsibilities — Consider a small part of the system

24. 1-24 Candidate Objects

25. 1-25 Poker Hand  Hopefully we found Poker Hand  What are it's responsibilities?

26. 1-26 Collaborative Activity  Form teams of 3 (neighbors will do)  Introduce yourselves — Name, where you are from, and something interesting about where you are from  Develop at least 10 things that should be tested in a Poker hand besides those on the next slide

27. 1-27 A few cases  Two hands have high card that are different  Two hands have high card that are same  A hand with a pair beats a high card hand  Two hands have one pair each that differ  Two hands have the same pair each where the pair is equal (compare highest cards outside pair)

28. 1-28 Consider JUnit  A problem and JUnit will be reviewed in section this week  The next few slides have examples of JUnit assertions

29. 1-29 A unit test with 2 test methods import static org.junit.Assert.*; import org.junit.Test; public class BankAccountTest { @Test public void testDeposit() { BankAccount anAcct = new BankAccount("Zac", 1000.00); assertEquals(1000.00, anAcct.getBalance(), 1e-12); anAcct.deposit(0.52); assertEquals(1000.52, anAcct.getBalance(), 1e-12); } @Test public void testWithdraw() { BankAccount anAcct = new BankAccount("Zac", 1000.52); assertEquals(1000.52, anAcct.getBalance(), 1e-12); anAcct.withdraw(10.52); assertEquals(990.00, anAcct.getBalance(), 1e-12); }

30. 1-30 Annotations  Useful annotations — @Test marks a test method — @Before marks a method that executes before every test methup — @BeforeClass marks a method that executes exactly once before the test methods exextute

31. 1-31 Assertions  Useful assertions that go into test methods public static void assertTrue(boolean condition) Asserts that a condition is true. If it isn't it throws an AssertionFailedError. public static void assertTrue(java.lang.String message, boolean condition) Asserts a condition is true. If not throw an AssertionFailedError with the message. public static void assertEquals(String message, Object expected, Object actual) Asserts that two objects are equal. If they are not an AssertionFailedError is thrown with the given message.  All other assertions of the Assert Class can be found at http://junit.org/apidocs/org/junit/Assert.html

32. 1-32 If time permits: Code Demo  The Movie concept from Test-Driven Development: A Practical Guide by David Astels — "We have a Movie class which now needs to accept multiple ratings (e.g., 3 as in “3 stars out of 5”) and give access to the average"  Code to be linked on our Code Demo page