The long way through Software Craftsmanship

GMaur code jam 2015: 01 - Mini-Power Swapper

Jan 12, 2015 - 1 minute read - Comments - code-jamgmaurkatakaizen

Last year we started the program 12 months, 12 katas (as inspired by this repository). This year we want to propose something different: an asynchronous code jam

##New problem: Mini-Power Swapper

This post belongs to a series: code-jam

Each month (or so) we at GMaur will publish a new problem (and announce it on twitter) and post a solution to the last problem.

This month, the Mini-Power Swapper

You can fork the repo, commit there and send a pull request. We’ll review the code (if you want) and merge the solution to a branch in “solutions/”.

Happy katas and happy code jamming!

Kata: Reverse Polish Notation in java

Jan 12, 2015 - 1 minute read - Comments - kataTDDjavaRPNreverse-polish-notationcalculatorusing-notes

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.

Listening to the tests

Jan 6, 2015 - 1 minute read - Comments - GOOSbookTDD

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

Talk: 'Is TDD Dead? Of course not! But what´s all the fuzz about then?' by Emily Bache

Jan 6, 2015 - 2 minute read - Comments - TDDtalkvideoemily-bachedhhnotesdesign

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