I attended a breakout session on jQuery right after lunch, but I didn’t have my laptop up and, honestly, it was a pretty high-level presentation of jQuery in any case. The technology certainly looks promising and I’ll have to find a way to play with it one of these days. Then again, I’m still trying to play with Scala and Mule, technologies I heard and read about after last year’s TSSJS. Aaaah…. where does the time go?
Agile based TDD sounds like a good session. As much as I keep wanting to move to TDD, I have a really difficult time doing so. Hopefully the more exposed I am to it, the easier it’ll become to actually use the methodology.
What is TDD?
Test-Driven Development is a software development process.
The TDD Process:
1. Write a failing test for the target behavior
2. Implement the behavior as simple as possible to get the test to pass
3. Refactor the implementation
TDD is a Design Activity
TDD treats Tests as VIP Artifacts: You need to treat your tests as first-class citizens
TDD is an “Agile” Practice:
1. Working software is the primary measure of progress
2. Continuous Attention to technical excellence and good design enhances agility
3. Welcome changing requirements, even late in development
Types of Tests:
1. Unit Testing: Verification of Design
2. Acceptance Testing: Verification of Features
What is a Unit Test?
Exercises a small testable piece of software
Tests a specific object behavior in isolation
Assumes that external dependencies work according to their contracts
Defines the assumptions that can be made of the target unitHow is unit test independent of its dependencies? Mock Objects
Tools and Frameworks
JUnit
Openpojo: a framework for validating that POJOs are adhering to a standard contract
Mockito: Mocking Framework – Declare dependencies with @org.mockito.Mock
The Benefits of TDD
Test-Driven Development improves Design
SOLID Design
* Single responsibility principle: Can do one thing really well, loosely coupled
* Open/close Principle: Encapsulation – What, not how?
* Liskov substitution principle: Contract first Design. Avoid inheritance unless “is a” …
* Interface Segregation Principle: Interface clients should only depend on methods they need
* Dependency Inversion Principle: Depend on Abstractions instead of mocking
TDD Follows Law of Demeter
TDD avoids Static Helper Classes: Procedural programming, not OO programming.
TDD Measures Progress, provides Documentation, and provides code coverage
How to Make it Work
* Flip Your Perspective – become a user, not a developer
* Always See Your Test Fail – make sure your tests have clear messages
* Listen to Your Tests – Urge to share test fixture state, setup, … => need to refactor
* Use an Interface Driven Approach
* Learn it well – TDD by Kent Beck
KATA
TDD Kata – Exercise in coding, refactoring and test-first, that you should apply daily for at least 15 minutes. -Roy Osherove
http://www.osherove.com/tdd-kata-1/