Mastering TDD

Two weeks ago I went to Paul Stringer’s course “Mastering TDD/BDD in iOS”. After the two days, I was exhausted… During the course, we looked at all the theory, completed some exercises. Paul gave us lots of links and books to read and, quite frankly, I was feeling overwhelmed.
I saw myself in front of the computer, with all those links to follow and read, and I didn’t know what to do… So I laid back on my chair and closed my eyes and thought… What do I know about TDD?

Following the rules…

Well, I know that it has laws:

  • You must write a failing test before you write any production code.
  • You must not write more of a test than is sufficient to fail, or fail to compile.
  • You must not write more production code than is sufficient to make the currently failing test pass.

I know I should follow the circle Red – Green – Refactoring:

  • Red – Create a failing test
  • Green – Write enough code to make the test pass
  • Refactor – Clean up your code and your tests (don’t forget that your tests are code too)

This works well to enforce the three laws of TDD. And as Kent Beck said:

Make it work. Make it right. Make it fast.

If you want to know all about the cycles of TDD, here is an excellent article by Uncle Bob

Going to your favorite school…

And there are schools… well not physical ones:

  • The Detroit/Chicago School or the Classicist approach
  • And the London School or the Mockist approach.

The first one uses real objects/classes and it tests the state of those objects. The second tests collaboration between objects and for that it uses mocks.
You have this article by Sandro Mancuso and this other by Jonathan Rasmusson that can help you distinguish them better.

Knowing your friends…

As an iOS developer, I tend to be more of a mockist since I drive my tests from the UI. And developing an app in Swift has some challenging aspects since we don’t have a Mocking framework… We do it all “by hand”…So yes knowing very well what kind of test double you need is a good thing. People tend to call them all mocks but as Martin Fowler said here:

Mocks aren’t stubs

But if you still have doubts about test doubles, this excellent article by Uncle Bob will definitely shed a light on it… (and I even found a version for Swift here). Magical!

Setting your priorities

Yes, that’s a really important one: use the Transformation Priority Premise to avoid big steps and to guide you into the generalization of your code. As Uncle Bob said:

[…]Refactorings have counterparts called Transformations. Refactorings are simple operations that change the structure of code without changing its behavior. Transformations are simple operations that change the behavior of code.

Another good article is this one by Pedro Santos.
Don’t forget that during the refactor phase your design skills are put to test: as Sandro Mancuso said here:

TDD is not a design tool. It’s a software development workflow that prompts for code improvement in its lifecycle. […]
The great thing about TDD is that it is constantly asking us “Hey, can you make your code better? See how hard testing this class is becoming? OK, you made it work. Here’s your green bar. Now make it better.”

Having good habits

TDD must be approached like a discipline. You must have good habits to stick with it. Here is the TDD good habits manifesto. This came up for the first time in SoCraTes UK ‘16 in a form of a session facilitated by Mani Sarkar and Pedro Santos, where they challenged us to add or remove practices to their original draft that you can see here.

Conclusion

Well, it seems that I have a minimum knowledge about TDD. Still need to practice a lot, and apply what I have learned when coding. Here are some books that you could read:

Code Smells – Part II

In the last post, Code Smells – Part I, I talked about the bloaters: they are code smells that can be identified as Long Methods, Large Classes, Primitive Obsessions, Long Parameter List and Data Clumps. In this one, I would like to dig into the Object-Orientation Abusers and the Change Preventers.

Object-Orientation Abusers

This type of code smell usually happens when object-oriented principles are incomplete or incorrectly applied.

Switch Statements

This case is simple to identify: we have a switch case. But you should consider it a smell too if you find a sequence of ifs. (That’s a switch case in disguise.)

Why are switch statements bad? Because when a new condition is added, you have to find every occurrence of that switch case.

So while talking to David, he asked me: and what happens if I encapsulate the switch into a method, is it acceptable then? That’s really a good question… If your switch case is only used to “take care” of one behaviour and that’s it, then it might be ok. Remember identifying a code smell doesn’t mean that you have to get always rid of it: it’s a trade off. If you find your switch statement replicated and each replication has different behaviour, then you cannot simply isolate the switch statement in a method. You need to find a proper “home” for it to be in. As a rule of thumb, you should think of polymorphism when you find yourself in this situation. There are two refactoring techniques that we can apply here:

  • Replace Type Code with Subclasses
    This technique consists of creating subclasses for each switch case and applying the respective behaviour to these subclasses.
  • Replace Type Code With Strategy
    Similar to the above one, in this case, you should make use of one of the patterns: State or Strategy.

So when to use one or the other? If the Type Code does not change the behaviour of a class you can use the Subclasses technique. Separating each behaviour into its appropriate subclass will enforce the Single Responsibility Principle and make the code more readable in general. If you need to add another case, you just add a new class to your code without having to modify any other code. So you apply the Open/Closed Principle.

You should use the Strategy approach when the Type Code affects the behaviour of your classes. If you’re changing the state of the class, fields and many other actions then you should use the State Pattern. If it only affects how you select a behaviour of the class then the Strategy Pattern is a better choice.

Hmm… It’s a little confusing, no? So let’s try with an example.

You have an enumeration EmployeeType:

And a class Employee:

It all looks ok. But what happen if you need to calculate the year bonus? You will add another method like this:

See the repetition of the switch? So let’s try first the subclass approach: Here is the superclass:

And here we have the subclasses:

With the Strategy approach we would create an interface for calculating the remuneration:

With the interface in place, we can now pass to the employee any class that conforms to that protocol and calculate the correct salary/bonus.

Temporary Field

This case occurs when we are calculating a big algorithm that needs several input variables. Creating these fields in the class has no value most of the time because they are just used for this specific calculation. And this can be dangerous too because you have to be sure you reinitialize them before you start the next computation.

Here the best refactoring technique is to use Replace Method with Method Object, which will extract the method into a separate class. Then you can split the method into several methods within the same class.

Refused Bequest

This code smell is a little tricky to detect because this happens when a subclass doesn’t use all the behaviours of its parent class. So it’s as if the subclass “refuses” some behaviours (“bequest”) of its parent class.

In this case, if it makes no sense to continue to use inheritance, the best refactoring technique is to change to Delegation: we can get rid of the inheritance by creating a field of the parent’s classes type in our subclass. This way every time you need the methods from the parent class you just delegate them to this new object.

When the inheritance is the correct thing to do, then move all unnecessary fields and methods from the subclass. Extract all methods and fields from the subclass and parent class and put them in a new class. Make this new class the SuperClass, from whom the subclass and parent class should inherit. This technique is called Extract Superclass.

Alternative Classes with Different Interfaces

Hmm, this case makes me think of “lack of communication” between members of the same team because this happens when we have two classes that do the same thing but have different names for their methods.
Start by Renaming Methods or Moving Method, so you can have both classes implementing the same interface. In some cases, only part of the behaviour is duplicated in both classes. If so, try Extract Superclass and make the original classes the subclasses.

Change Preventers

Oh boy! This kind of code smells are the ones you really want to avoid. These are the ones that when you make a change in one place, you have to go basically throughout your code-base making changes in other places too. So it’s a nightmare that all of us want to avoid!

Divergent Change

This is the case when you find yourself changing the same class for several different reasons. This means that you are violating the Single Responsibility Principle (which has to do with separation of concerns).

The refactoring technique applied here is Extract Class since you want to extract the different behaviours into different classes.

Shotgun Surgery

This means that when you make a small change in a class, you have to go and change several classes at the same time.

Even though it seems the same as the Divergent Change smell, in reality, they are opposite of each other: Divergent Change is when many changes are made to a single class. Shotgun Surgery refers to when a single change is made to multiple classes simultaneously.

Here the refactoring technique to apply is Move Method and/or Move Field. This will permit you to move the duplicated methods or fields to a common class. If that class doesn’t exist, create a new one. In the case where the original class stays almost empty, maybe you should think if this class is redundant, and if so, get rid of it by using Inline Class: move the remaining methods/fields to one of the new classes created. This all depends on whether the original class still has any responsibilities.

Parallel Inheritance Hierarchies

This case is when you find yourself creating a new subclass for class B because you add a subclass to class A.

Here you can: first, make one of the hierarchy refer to instances of another hierarchy. After this first step you can then use Move Method and Move Field to remove the hierarchy in the referred class. You can apply here the Visitor pattern too.

Conclusion

In the case of Object-Orientation Abusers and Change Preventers, I think that they are simpler to avoid if you know how to apply a good design to your code. And that comes with a lot of practice.

Today I’ve talked about a few refactoring techniques, but there are a lot more. You can find a good reference to all of then in Refactoring.com.

And as I said in the first part of this series, code smells can’t always be removed. Study each case and decide: remember there is always a trade off.

Code Smells – Part I

Last weekend I was at SoCraTes Canaries and I gave my first talk ever about code smells. Oh boy! How nervous was I! But now that has passed, I was wondering what I should do with all information I gathered. And then I thought, maybe it’s a good idea to put it all in a nice blog post.

So what are code smells?

As Martin Fowler said in his book “Refactoring: Improving the Design of Existing Code”,

A code smell is a surface indication that usually corresponds to a deeper problem in the system.

I like to think that a code smell is something that makes your developer instinct cry out to you, and you just know that something is wrong. This doesn’t mean you have to make changes in your code: there are occasions where these code smells are ok, but I think it’s important for us to detect them and know exactly why they are there.
There are five categories of code smells:

  • Bloaters
  • Object-Orientation Abusers
  • Change Preventers
  • Dispensables
  • Couplers

Today I’m going to talk about Bloaters. I’ll leave the other categories for a future post.

Bloaters

Bloaters can be big methods or classes, primitive obsessions, data clumps, or long parameter lists.

Long Parameter List/Data Clumps

The Long Parameter List is when you have a method that has more than 3 parameters. Sometimes we see that when we receive an object, and instead of passing it all we pass some of its data. In this case, the best policy is to pass the whole object. Data Clumps are a bit different: they are, in general, primitive values that start to “get together”. A good example of this is a startDate and endDate… Maybe it’s worth creating a DateRange.

Primitive Obsession

This case is when we use primitives instead of value types for simple tasks. Sometimes the use of primitives is justifiable, but when you start to have behaviour attached to this primitives, then it’s time to stop and think that maybe a value type is in order. A simple example is a currency: we tend to put it in a float or double, instead of encapsulating it in a value type.

Long Method / Large Class

This kind of code smell happens when you have a big method. But when do you know that a method has become too big? Well, I have the rule that with more than five lines, you should, at least, look at it again. But, as Sandro told me before, the right number of lines is just enough lines so a method only does one thing (and so it conforms to the 1st principle of SOLID the Single responsibility principle).

To do this blog I started to look at my old code when I hadn’t woken up yet to craftsmanship: if it was working that was good enough for me. Here’s the code in Objective-C:

Wow! This is a really big method. And it is inside a ViewController class, so this should definitely be extracted into a service class, so we have a correct separation of concerns. But for the sake of the brevity, let’s focus on how can we refactor this big method.
The refactoring technique to apply here is Extract Method: you can aggregate code together and extract to a new method. So let’s see what we can come up with:

We can start with grouping the code that refers to serializing a post:

Then we can do it for the parameters of the request:

With all this in place we are now ready to create a XMLRPCRequest:

We can also extract a method with some display updates:

And last but not least we can extract the preparation for displaying the error message:

With all these extractions our method now looks pretty neat:

Hmm… we can do this even better! Let’s take a look at the method createXMLRCPRequest and see if we can call the others from there. In this case, it makes sense to have all together.

And our original method now looks like this:

Well, here you go: a method with more than 5 lines and I think that’s ok. 🙂
As we can see it’s really easy to let a method grow. But it’s really easy to refactor and have a cleaner code too.

Conclusion

In general, bloaters are viewed as code that, over time, “gets out of hand”.
Remember, code smells sometimes can’t be removed, but it’s good to know that they are there and you know why they are there.