TDD – Have a Common Understanding in the Team

Recently I’ve been paying more attention to my style and approach to  TDD, and in doing so, I’ve begun to notice a few interesting things which, to me, seemed natural and almost “part of the process”, but clearly thats not the case with everyone. When I start on a dev task I typically try to ask as many of the right questions(see my previous post about avoiding autopilot) before I set off diving into code. I like to set the expectations of what it is that needs to be achieved, which is perfect in the world of TDD, because ultimately your tests should be testing the expectations match what actually happens.

I’ve come to learn that this isn’t necessarily the same “naturally assumed” approach which other developers might take. And along with that, there is mostly a misunderstanding within the team about what constitutes a focussed test, as well as what constitutes the definition of a category of tests. i.e. What qualifies as a unit test vs an integration test? And when to use them?

An experiment – collecting opinions

I thought I’d embark on a quick experiment and ask colleagues around me what their view on TDD is. Not surprisingly, there were a lot of different views and almost everyone I spoke to had a somewhat different idea of what TDD should be. Some advocating integration heavy tests to ensure business scenarios work, others advocate unit tests for quicker feedback etc. But what I found most interesting is that the definition of what a unit, integration, functional, end to end tests varied depending on who I spoke to! It became clear that is was common place to hear different vocabulary being used to describe the same end goal. For example I’d heard the terms “system testing”, “integration testing” and “acceptance testing” as well as “UAT” to all mean the same thing!

Clearing the  air

Obviously its fruitless to be embarking on a TDD journey if everyone int the team has a different idea of what its supposed to be. Most of the time when you hear the acronym “TDD” its automatically assumed to be unit tests that you’re writing, and for the large part, that might hold true. But I’m going to include other categories of testing that I feel should form part of the TDD paradigm. The definitions I supply below are not to be taken as solid regimented definitions, but more a way for teams to have a common understanding of what each area of TDD you’re targeting.

The Definitions

So lets clear the air a bit and define what is what. I’m obviously not the first person to write about the difference between unit and integration tests etc, but here’s what I find works:

Unit Test

A test that focuses on a single segment of behaviour. i.e. test that adding money to an account increases the overall balance. These tests should provide feedback as quickly as possible, and must run on every code change. And most importantly, a unit test is not something that touches 3rd party libraries/frameworks or resources which you have no control over. This includes interactions with a database, files system, and network comms as an example. Some might dispute that interactions between classes or modules that even you have written would be dumped in the integration category, but I disagree.

Integration Tests

Focussed on ensuring aspects of your code that interact with 3rd party libraries/frameworks and resources interact in the way you expect them to. i.e. writing an export file to disk, or saving an entity to the database successfully. These tests probably wouldn’t be run quite as often as your unit tests, as they could become quite heavy over time as the application grows. Typically, in most organisations I’ve worked in, these tend to run on every continuous integration build, and not necessarily on every code change – which included changes made while developing.

End to End/Acceptance Tests

Ensures that a business feature works as expected. This could include real world business scenarios from either through an API that has been built, or even through the UI – although this could be a whole other topic for another time. The point is, these end-to-end tests won’t run as frequently, and they will only test the core business scenarios. They involve complete vertical calls, and tend to be very CPU intensive, and are known to take large amounts of time to run. Especially as the application grows. Typically, you would have these run once a day, perhaps on a scheduled nightly build. If you happen to have introduced BDD into your development environment, these would be the tests I would expect to see running here.

So in summary, the real point here is that I was a little surprised that still to this day, many developers have a different take on what TDD is, and how to approach it, which might be fine, but in order for a team to produce good quality solutions and efficient code bases, then at the very least these teams all need to have a common understanding of what sort of tests they’re writing. Without it, your on a road, that will end in pain. Big pain.

Advertisements

Avoid “autopilot” behaviour when developing

I love coffee. And there’s a pretty good coffee place close to where I work that I regularly frequent out of the addiction I have now acquired for caffeine. Not to mention that I may possibly  need it in order to turn me into a less “abrasive” individual in the morning. 🙂 For the passed week or so, the conversation has gone a little like this:

Barista: Hi there, what I can I get you?

Me: I’d like a medium white americano, to have in please.

Barista: Americano?

Me: Yes

Barista: What size?

Me: Medium please.

Barista: To take away?

Me: No, to have in.

Barista: Would you like milk with that?

Me: Yes.

Now, this happens almost every time I go, and it got me thinking about some particular traits I’ve picked up on while working with some inexperienced software developers. When given a requirement, they almost instantly go into autopilot, and just begin coding, not always asking the right (or even at all!) the much needed questions that they should. On the other extreme, as in the case of the barista, sometimes they ask all the questions which were already answered in the first statement! As you can imagine, both ends of the scale result in a lot of wasted time. Clearly this barista was(and still is!) on autopilot, just asking the usual questions, and not really listening.

Inexperienced software developers have a tendency to just want to get stuck in a code away. I’ve been there, done that, and also subsequently been burnt by it. Resist this urge. Don’t assume you know the domain well enough to begin coding. Look at the problem you’re trying to solve first. Listen to the requirement and the context its in, and try to ask the right questions, and especially try not to ask the same questions which have already been answered, except for in the case where you are confirming your understanding.

I honestly think that if every developer did this, fewer bugs, fewer misunderstandings, and fewer under delivering to expectations would occur. If you need a little help on fighting the urge to code, then I’d suggest that you use the 5 Whys approach. If anything, this approach should help you contextualise the problem, and promote a discussion to lead you to ask the right questions before rushing in to code.

Taking the plunge, going contracting!

Recently I’ve been deliberating with a lot of energy mind you, about where I am in my current career as a software developer, and how that marries with where I’m at in my current position at my company. For reasons I won’t divulge here, suffice it to say I’m not completely happy I’m heading in the right direction, and have chosen to resign and move on.

With moving on there’s, always the choice between finding another permanent position, or to take the plunge and going contracting. I’ve had a few frank discussions with friends and ex-colleagues about the merits of both, and there was a definite positive bias of opinion towards contracting. Not only just the benefits of extra cash in your back pocket – provided you’re good enough – but also contracting is inherently associated with freedom.

Show me the money!

Everyone you speak to when it comes to contracting will at some point, if not the first point, mention that the money is better. You have the luxury of getting more cash in your back pocket – remember always do it above-board when it comes to taxation, it’s really not worth it! – but you take the risk for if ever there are quiet times in the industry. You’ll obviously be responsible for things like your own medical, pension, training, equipment etc. Which is why you can demand a higher rate, and what also works in your favour is that the higher rate is only subject to a finite amount of time – i.e contract duration. Believe it or not, this is quite an attractive thing for companies seeking sections of work to be completed, because they already know what it will cost them up front – I guess provided they know the scope etc. I’ve been in software development long enough to know that it is rare for someone to quote a fixed duration of time to deliver a product/feature, and it being delivered on time! :-p But the point I’m really trying to make here is that the company hiring the contractor, can cease the need for any further expenditure once the contract is up. When you’re permanently employed, the company can’t quite do that as easily.

Travelling

With contracting, you’re committed for a set period of time, to deliver a service. After the contract is finished, you can decide to either extend/find a new one. Or you could choose to do some things which you’ve always wanted to do. I love travelling, and especially travelling with my girlfriend. She’s a teacher and during the summer we’ve dreamed of taking weeks off to go travelling, which she’s more than capable of doing, but I unfortunately historically couldn’t. Most permanent employment have restrictions on the number of consecutive weeks you can take off, and also the number of days off that you can have in the year. This is completely negated when you contract. Travelling or even learning to play an instrument are totally within your control provided you do a little bit of planning, and save the extra cash you’re now getting while contracting. 🙂

Training

When contracting you would be in charge of your own progression. That really appealed to me. I decide what courses I want to attend, and what new technologies I want to experiment with. This is obviously not to say that I didn’t have those choices in a permanent position, but when contracting you’re free from the shackles of pay-back schemes, and lock-in, as well as avoiding situations where in quiet times the company can’t send you on training due to budget cuts. This is another reason why you can demand higher rates, so that you can keep up with the industry. Also, and possibly more valuable in my opinion, is that every new contract you work on, exposes you to new things, new technologies, new implementations of methodologies etc. This is an incredibly important asset to have.

So these are just my reasons and opinions for going contracting. It’s scary to take the plunge, but I’m sure when I finally do land my first contract, I’ll never look back. While doing incessant and relentless research on this topic, I was given a book by a dear friend of mine, and this was something like a bible to me. Its called the Contractors’ Handbook, and is more geared for UK individuals wanting to go contracting. Its written by Dave Chaplin, and he’s got a new version of this book coming out in June, so check it out here, I can’t recommend it enough if you’re becoming serious about contracting.

So, are you thinking about going contracting now? 🙂