June 5, 2017

Learn TDD with Codemanship

The Codemanship TDD "Driving Test" - Initial Update

A question that gets asked increasingly frequently by folk who've been on a Codemanship TDD workshop is "Do we get a certificate?"

Now, I'm not a great believer in certification, especially when the certificates are essentially just for turning up. For example, a certificate that says you're an "agile developer", based on sitting an exam at the end of a 2-3 day training course, really doesn't say anything meaningful about your actual abilities.

Having said all that, I have pioneered programs in the past that did seem to be a decent indicator of TDD skills and habits. First of all, to know if a juggler can juggle, we've got to see them juggle.

A TDD exam is meaningless in most respects, except perhaps to show that someone understands why they're doing what they're doing. Someone may be in the habit of writing tests that only ask one question, but I see developers doing things all the time that they "read in a book" or "saw their team doing" and all they're really doing is parroting it.

Conversely, someone may understand that tests should ideally have only one reason to fail so that when they do fail, it's much easier to pinpoint the cause of the problem, but never put that into practice. I also see a lot of developers who can talk the talk but don't walk the walk.

So, the top item on my TDD certification wish-list would be that it has to demonstrate both practical ability and insight.

In this respect, the best analogy I can think of is a driving test; learner drivers have to demonstrate a practical grasp of the mechanics of safe driving as well as a theoretical grasp of motoring and the highway code. In a TDD "driving test", people would need to succeed at both a practical and a theoretical component.

The practical element would need to be challenging enough - but not too challenging - to get a real feel for whether they're good enough at TDD to scale it to non-trivial problems. FizzBuzz just won't vut it, in my experience. (Although you can weed out theose who obviously can't even do the basics in a few minutes.)

The Team Dojo I created for the Software Craftsmanship conference seems like a viable candidate. Except it would be tackled by you alone (which you may actually find easier!) In the original dojo, developers had to tackle requirements for a fictional social network for programmers. There were a handful of user stories, accompanied by some acceptance tests that the solution had to pass to score points.

In a TDD driving test, I might ask developers to tackle a similar scale of problem (roughly 4-8 hours for an individual to complete). There would be some automated acceptance tests that your solution would need to pass before you can complete the driving test.

Once you've committed your finished solution, a much more exhaustive suite of tests would then be run against it (you'd be asked to implement a specific API to enable this). I'm currently pondering and consulting on how many bugs I might allow. My instinct is to say that if any of these tests fail, you've failed your TDD driving test. A solution of maybe 1,000 lines of code should have no bugs in it if the goal is to achieve a defect density of < 0.1/KLOC. I am, of course, from the "code should be of high integrity" school of development. We'll see how that pans out after I trial the driving test.

So, we have two bars that your solution would have to clear so far: acceptance tests, and exhaustive testing.

Provided you successfully jump those hurdles, your code would then be inspected or analysed for key aspects of maintainability: readability, simplicity, and lack of duplication. (The other 3 goals of Simple Design, basically.)

As an indicator, I'd also measure your code coverage (probably using mutation testing). If you really did TDD it rigorously, I'd expect the level of test assurance to be very high. Again, a trial will help set a realistic quality bar for this, but I'm guessing it will be about 90%, depending on which mutation testing I use and which mutations are switched on/off.

Finally, I'd be interested in the "testability" of your design. That's usually a euphamism for whether or not dependencies betwreen your modules are easily swappable (by dependency injection). The problem would also be designed to require the use of some test doubles, and I'd check that they were used appropriately.

So, you'd have to pass the acceptance tests to complete the test. Then your solution would be exhaustively tested to see if any bugs slipped through. If no bugs are found, the code will be inspected for basic cleanliness. I may also check the execution time of the tests and set an upper limit for that.

First and foremost, TDD is about getting shit done - and getting it done right. Any certification that doesn't test this is not worth the paper it's printed on.

And last, but not least, someone - initially me, probably - will pair with you remotely for half an hour at some random time during the test to:

1. Confirm that it really is you who's doing it, and...

2. See if you apply good TDD habits, of which you'd have been given a list well in advance to help you practice. If you've been on a Codemanship TDD course, or seen lists of "good TDD habits" in conference talks and blog posts (most of which originated from Codemanship, BTW), then you'll already know what many of these habits are

During that half hour of pairing, your insights into TDD will also be randomly tested. Do you understand why you're running the test to see it fail first? Do you know the difference between a mock and stub and a dummy?

Naturally, people will complain that "this isn't how we do TDD", and that's fair comment. But you could argue the same thing in a real driving test: "that's not how I'm gonna drive."

The Codemanship TDD driving test would be aimed at people who've been on a Codemanship TDD workshop in the last 8 years and have learned to do TDD the Codemanship way. It would demonstrate not only that you attended the workshop, but that you understood it, and then went away and practiced until you could apply the ideas on something resembling a real-world problem.

Based on experience, I'd expect developers to need 4-6 months of regular practice at TDD after a training workshop before they'd be ready to take the driving test.

Still much thinking and work to be done. Will keep you posted.




May 29, 2017

Learn TDD with Codemanship

Software Craftsmanship 2017

It's early days, but planning is underway for this year's Software Craftsmanship conference.



Since it returned last year, SC20xx has evolved from a conference where talks were banned, to a conference with no fixed sessions at all. We stripped it down to the bare essentials of what folk said made previous SC conferences fun and worthwhile. Basically, we want a chance to meet likeminded code crafters, socialise, exchange ideas, and - most of all - code.

Instead of scheduled sessions, we'll have the space and the resources needed to tackle interesting and challenging programming projects. Work in pairs, work in groups, work by yourself (although, really, why come all that way to work alone?) Build a bot. Write a tool. Start a tech business. Put your Clean Code skills to the test. It's all good.

SC2017 will be on Saturday Sept 16th, and last year we had events being hosted in London, Manchester, Bristol, Munich and Atlanta, GA. This year, we're hoping for even more hosted events all around the world. It doesn't require much organisation, so drop me a line if you're interested in running one where you are.

Unofficially, the London event is already open for registration (there's a small fee to cover costs - SC2017 is a non-profit event), and more details will be posted soon.

Follow @softcraftconf for updates.





March 2, 2017

Learn TDD with Codemanship

101 TDD Tips - Complete Series

For the last 3 months, I've been posting tips for doing Test-Driven Development for effectively and sustainably to the Codemanship Twitter feed.

The series is now complete, and you can read all 101 TDD tips in this handy PDF




February 2, 2017

Learn TDD with Codemanship

101 TDD Tips - #1-#80



We're now up to number 81 in my 101 TDD Tips series on Twitter, and I've pasted numbers 1-80 into a handy PDF for your convenience.



January 20, 2017

Learn TDD with Codemanship

TDD 2.0 - London, May 10th

After the success of last week's TDD 2.0 training workshop, I've immediately scheduled another one for the Spring.

Powered by Eventbrite


It's 3-days jam-packed with hands-on learning and practice, covering everything from TDD basics and customer-driven TDD/BDD, all the way to advanced topics other courses and books don't touch on like mutation testing and non-functional TDD.

And it comes with my new TDD book, exclusive to attendees.

If you fancy a code craft skills boost, twist the boss's arm and join us on May 10th.



January 14, 2017

Learn TDD with Codemanship

Codemanship Alumni - LinkedIn Group



Just a quick note to mention that there's a special LinkedIn group for folk who've attended Codemanship training workshops*.

With demand for skills like TDD and refactoring rising rapidly, membership is something you can display proudly for interested hirers.



* You'll need to list details of Codemanship training courses you've attended (what, when, where) on your LinkedIn profile so I can check against our training records.




January 9, 2017

Learn TDD with Codemanship

Last Call for TDD 2.0 - London, Wed-Fri

Just a quick note to mention I've got a bit of space of available for this week's jam-packed TDD 2.0 training workshop in London.

January can be a quiet period for dev teams, so twist the boss's arm and take advantage of some slow time.

https://www.eventbrite.co.uk/e/tdd-20-london-tickets-28548787191




December 19, 2016

Learn TDD with Codemanship

Start The New Year With A TDD Skills Boost

Just a quick reminder about the next public TDD training workshop I'm running in London on Jan 11-13. It's the most hands-on and practical workshop I've ever done, and at about half the price of the competition, it's great value. And, of course, you get the exclusive TDD book. Not available in any shops!

Powered by Eventbrite




October 26, 2016

Learn TDD with Codemanship

101 TDD Tips Digest

I've been posting a TDD tip every weekday on the @codemanship Twitter feed, and we're now up to #20.

Folk have asked where they can get all the tips so far, in order (Twitter's not good at that sort of thing), so I've pasted them into a TDD Tips PDF digest (via this page) for your convenience, which I'll update every 20 tips.

Keep your eyes peeled on the Twitter account for new tips.



October 12, 2016

Learn TDD with Codemanship

Evil FizzBuzz

The major upgrade to the Codemanship TDD training workshop launched at the weekend, and - while much has changed - what would a TDD workshop be without FizzBuzz?

But the practical exercises in TDD 2.0 have been turbocharged...

Evil FizzBuzz (or "Continuous FizzBuzz") is my take on a Continuous Integration kata - we just don't do enough of those, right? - where each par of the FizzBuzz problem has been isolated in its own user story.



Teams must split up the work, with each developer (or pair of developers) picking up one user story at a time, test-driving the code just for that story, and continuously integrating with the other members of the team who are simultaneously working on other stories.

Committing to the same GitHub repository, with a cloud build pipeline set up to compile the code and run all the tests, this is a challenge in not tripping over each others' feet. It takes effective coordination and communication. Again, something we just don't practice enough.

The goal is to complete it quickly without breaking the build. To make it even more interesting, assign a single developer to take the challenge by themselves and see who finishes faster.