I’ve written a RPN string calculator in java, using TDD with these: mockito, hamcrest, junit

It’s close to the String Calculator kata, by Roy Osherove. This RPN is using mocks (so more difficult than the String calculator)

I’ve tried to practice “Your tests are dragging you down” by J.B Rainsberger (mainly, to use something to write on). This behavior is also explained in the book Dirigido por tests (Spanish) by Carlos Blé.

My solution is here. Every step (red, green, refactor) has been saved.

Specifically the chapter no. 20 (“Listening to the tests”) from Growing Object-Oriented Software Guided by Tests available here is so good to learn to hear to your tests.

To hear what they’re trying to tell you, the authors (Steve Freeman and Nat Pryce) explain this to you:

• I Need to Mock an Object I Can’t Replace
• Logging Is a Feature
• Mocking Concrete Classes
• Don’t Mock Values
• Bloated Constructor
• Confused Object
• Too Many Dependencies
• Too Many Expectations

To close, a quote:

[…] We’ve found that the qualities that make an object easy to test also make our code responsive to change

Growing Object-Oriented Software Guided by Tests, chapter 20, page 229

I just did the prime factors kata, in java using TDD. Results: https://github.com/alvarogarcia7/primeFactors

Code review, comments, pull requests are more than welcome

Source: http://craftsmanship.sv.cmu.edu/katas/prime-factors-kata

Source: http://butunclebob.com/ArticleS.UncleBob.ThePrimeFactorsKata

I’ve just seen this talk: Is TDD dead? Of course not! But what´s all the fuzz about then? by Emily Bache

My notes

• deliberate vs accidental learning (around minute 19)

• do not be an evangelist for tdd but rather “come learn tdd, come at a dojo with us!”

• points to Dan North’s talk (at the same foo café)

• points to her book - The Coding Dojo Handbook

• points to cyber dojo

• design is hard whether you do TDD or not

• dhh: too much focus on unit test.

I thought we got rid of best practices in agile

• different kinds of advice for each kind of target (eg, based on experience level)
• points to self-testing code (by Martin Fowler)
• problem: the test suite is no longer in sync with the production code
• points to approval testing:
  • code kata “minesweeper”
  • test data + code produces output data
  • I approve the data
  • Useful for full features
  • Useful for asserting on difficult parts like images
  • realistic users to generate tests
  • tool to manage these “approval tests”. Easy way of managing tests cases
  • TextTest is one of these tools

Her conclusions

• Watch out the fundamentalism
• TDD might take you to too many layers of indirection
• The share of each test (end to end, integration, unit) depends on each project / part
• Many TDD pieces of advice is directed to novices. When you’re not, you should know when to stop listening

PS: I’ve first seen this video in garajeando

This category is mainly dedicated to anything related or included in the book ‘Growing Object-Oriented Software Guided by Tests’, by Nat Pryce and Steve Freeman

Note: This has been created a posteriori with a previous date

Books I’ve read this quarter Q4 on 2014, as inspired by Manuel, on this post:

• ATDD by Example: A Practical Guide to Acceptance Test-Driven Development by Markus Gärtner
• Head First Design Patterns by Eric Freeman, Elisabeth Robson, Bert Bates, Kathy Sierra
• Apprenticeship Patterns, Guidance for the Aspiring Software Craftsman by Dave Hoover, Adewale Oshineye
• Diseño ágil con TDD, by Carlos Blé Jurado; again
• The Mythical Man-Month, Anniversary Edition: Essays On Software Engineering by Frederick P. Brooks Jr.
• Implementation Patterns by Kent Beck

Books started, not yet finished (WIP):

• do not remember if there were any

(Note: I’ve written this list a posteriori, in May 2015)