It’s been a while since I wrote code these days. Back in late April however I found myself in a Coding Dojo at the Düsseldorf Softwerkskammer meet-up working on the Mars Rover Kata. I have a story to share from that meeting. However, since I tried to reproduce the code we ended up with that night, and I decided to give JUnit5 (and Java8) a go for that, I ended up with a struggle.
Back in the days with JUnit4 I used the ParameterizedRunner quite often to use data-driven tests. I never remembered the signature of the @Parameters function, though. The Mars Rover Kata also includes some behavior that I wanted to run through a data-driven test, but how do you do that in JUnit5? I couldn’t find good answers for that on the Internet, so I decided to put my solution up here – probably for lots of critique.
Please note that I used JUnit 5.0.0-SNAPSHOT which is a later version than the alpha, but probably not the final one.
A couple of years ago I read a book from Michael Feathers that kept on being mentioned a lot in the literature I was reading then. The title? Working effectively with legacy code. Feathers makes some points on how to get code without tests working, by breaking down dependencies, introducing seams, and working towards more testable code. I loved that book.
When we take the idea of test automation as software development seriously, then there also should be a concept called legacy tests. That concept to me is related to testing debt, a term I think I coined back in 2009. But what are legacy tests? How do they slow down your productivity? And what can we do about it?
Here are some limited experiences I made with a couple of legacy tests, and how to overcome them. I hope this blog entry will trigger some more experience reports from folks, so that fewer teams need to suffer from it.
Years ago, I wrote a book on ATDD. Only years later I notice the value that this practice can bring to an environment with multiple teams working together on the same platform. The connection to scaling agile in the larger enterprise wasn’t that obvious than it became when I started to dive deeper into how to scale agile. Though, most larger enterprise struggle with getting one team running, scaling has become the latest fuzz in the agile community. Let’s see why ATDD is relevant for this sort of environment, and how you can challenge your team colleagues about it.
There is a misconception floating around that Agile Testing is mostly about automated checking. On the other way the whole testing community fights since decades about the value of test automation vs. the value of exploratory testing. I find these two different extreme position unhelpful to do any constructive testing. Most recently I ended up with a model that explains the underlying dynamics quite well, to testers, to programmers, and to their managers. Here’s the model.
Last Saturday we had the first testautomation coderetreat in Munich. Woohoo! This was a kickstart for this new coderetreat format – besides the original one from Corey Haines, and the Legacy Coderetreat format from J.B. Rainsberger. Here is my report from the facilitator’s point of view and with some hints about what I am going to try at different other follow-up coderetreats.
It’s been quite a journey since I approached Kent Beck with the idea for the first time two years ago. As I was unsure whether I could actually write a book in a non-native language, I decided to give it a try during the Pragmatic Programmer’s Writing Month in November 2010, and completed the first part from three within the first month. Skip forward a few months, and there it finally is.
Now, with every book you as the author face two main struggles:
when to stop believing that you can incorporate new stuff that you learned in the meantime so that the content will not be out-of-date
when to stop polishing up what you have so that any mistakes that are still there get exposed to the public – and finally show your readers how bad an author and writer you are
For the first of the two points, I was glad to incorporate some of the stuff that I learned while finishing up the major draft version around New Year’s and now in a series of articles for inform IT. The first one of these will get you started with ATDD. It’s called Getting Started with ATDD: Overcoming the Biggest Mistakes Right from the Start.
For the second point, I have a deadline nearby middle of July to return any corrections for the second printing by then. So, if you happen to find any “bugs” in the final manuscript – and I know there are lots of it, although I decided to read through it several times – I would be more than glad if you dropped me line about it, so that I can get it corrected in the next printing.
I figured that I spread around some easter eggs from time to time in the projects that I am involved in. If you happen to find one, please keep it to yourself in order not to spoil others who are looking for it. I think I should set up a challenge around this some time in the future. Maybe I will spread a free copy of my next book then.
On the title, why did I call it ATDD by Example rather than Specification by Example by Example: Well, I think the name “Specification by Example by Example” would be stupid. A recent client gig where I consulted on “Specification by Example” I also found myself in the situation where a business expert asked me: “Does Specification by Example mean ‘all specifications’?” Since then I am convinced that we didn’t solve the naming problem – and I wonder if we will have to. For more on the name, make sure to read the preface. I explain why I picked that particular name – and a whole lot more on the background.
One final word: If you enjoy the book, tell others, so they read it. If you are disappointed or have any criticism, please tell me so that I can improve myself. Thanks. Enjoy.
If you want to become one of the former group, here is a coding kata for you. I derived this from a tester at a client who is currently pursuing his Computer Science degree. While he was asking for help on an exercise, we came up with the idea, that this exercise would be a pleasant coding kata.
A while ago, I called for some participation on the state of our craft. I promised back then to present some intermediate answers in late January. Here they are.
One of my colleagues made a claim yesterday which I would like to put some numbers on. I raised the question on twitter, and received suspicious answers about the numbers of my colleague. Please forward this survey to anyone you know who is programming: http://www.shino.de/programmer-survey/ It consist of just four question, so you should be able to answer them in a few minutes.
Over twitter I also received the feedback that things are worse for testers. I would like to put numbers on that as well. Therefore I also put up an equally small survey for tester: http://www.shino.de/tester-survey/ Please forward this survey to anyone in the software business that you know of.
From time to time to I will publish some of the results. I aim for end of January for the first set of data.
