JUnit’s ExpectedException @Rule

Some time ago I had written a post about different ways to deal with exceptions using JUnit. It’s time to augment that post with a truly great way to achieve the same result.

Let’s look at this through an example. The task will be to implement a little method for an insurance company that registers a car to be insured by its license plate number. In Hungary, license plates follow the LLL-DDD pattern, where L stands for an uppercase letter, while D is a digit from 0 to 9. The initial requirement is simple: validate whether the input string conforms to the pattern described above; if it does, save it, else, throw an IllegalArgument exception. Continue reading “JUnit’s ExpectedException @Rule”

Advertisements

Single responsibility principle : a Kata

Some time ago I was browsing on http://rubyquiz.com/ and found a really interesting exercise there. It’s name is Getting to 100. The rules are quite simple:

  1. You are given the sequence of numbers 123456789
  2. Each number in the interval [1-9] has to be present in the sequence
  3. Each number must appear once and only once
  4. Numbers should be in increasing order
  5. You are given three operators: two minuses and one plus that you have to insert between those numbers
  6. The resulting equation should be give 100

The actual task is to:

Unit testing tips and tricks

There are some common patterns when it comes to unit testing. Not very hard to solve situations, however, it might take a little time to find a solution to them, especially for the first time.

In this post I’d like to share some ideas that always pop up when someone new to unit testing joins our team. These things may seem trivial after some practicing, but still. Someone might find it useful. The code examples will be in Java, the mocking -when applicable- will be done using JMock (the same principles apply to Mockito). Continue reading “Unit testing tips and tricks”

Self improvement group – some feedback

Well, the following post is about some feedback I’ve recently received on my activity regarding our self-improvement group. I was really about to abandon the whole thing, but my friend Lajos Fülep’s kind words made me continue.

In the last two weeks our little self development group was busy with a brand new topic: namely legacy code (legacy code in the sense of: “code that is working suspiciously, and have no tests around it.”).  Some time ago I’ve posted some really ugly code that is full of bugs and has no tests at all. As discussed there, two rounds should be taken: one for adding tests , another one for refactoring it (and fixing the numerous bugs the code contains).

The first round was a pair programming session. The task was to cover the code as much as possible, and spot the mistakes – spot but, don’t touch them (hint: there are at least four major bugs in there). This task can be implemented in an hour. After that, we choose a reference implementation for the second round.

The second round is done randori-based. It means that there is a single laptop along with a projector, while people keep rotating in front of the computer. Everyone is allowed to make a single change. A single change can be: extracting a method, extracting a class, renaming TWO methods, variables etc. Basically the “one change” rule can be adjusted as you wish. I was kind of afraid of this randori-session; I thought people would be afraid of being creative while all fellow group members are looking at them. However, it went really well; people kept saying “I want to stay, this was half a change only”. What is very important here is that anyone not in front of the computer can speak only after the next change to be made has been named by the person at the computer. This means that you cannot give tips what to be done next (only if it was requested explicitly), but can argue whether a change is needed or makes sense at all.

Here’s the feedback I’ve received (translated from Hungarian):

I found this session very useful. What I liked about it was the task itself.  It was cool we had to refactor an ugly piece of code. On the other hand it was very useful to me to see how other people were working and thinking. Way to go 🙂

Code refactoring in progress :-).

Three ways of injecting dependencies

I know, I know, this has already been said at least a million times, but as I see it’s not yet obvious to everyone. So, in real short, let’s talk about three ways of injecting your dependencies and their pros and cons. Continue reading “Three ways of injecting dependencies”

Hey Ho, Let’s Go (Agile again)

I’ve already complained enough about us not being agile enough. I also realized that complaining and crying will not help us solve the situation we got into. There were a few problems arisen, ranging from tiny to not-so-tiny. Of course most of them will not go away overnight. It’s useless to tell “we’re doing completely wrong” and not to do anything about it. As one of my former colleagues would always say, “the s**t has to go away”. However, it only goes away if we found out which the s**ty parts were. Continue reading “Hey Ho, Let’s Go (Agile again)”

TDD avoidance – Top 10 reasons

I’m sad to see we somehow got way too far from agile coding, best practices and quality. It seems that TDD has its life cycle curve inside our organization (who knows, maybe we can generalize further). At the beginning everyone is excited about the new way of working. They seem to be adapting things, trying out TDD, mocking and the other technologies. After a while, however, people feel test driving feature development is a waste of time. So they stop writing test cases and get back to their old way of working. At the end, the organization is left with very few people committed to TDD.

And this is the strange part. Quality drops, because nobody cares about it, but when it gets noticeable everybody cries around. And that is the point when people start shouting louder: “This code is pretty much a mess, we’d rather rewrite the whole thing”. A friend of mine told me the other day “you cannot expect people to be writing test cases; they lack dedication”. (By the way, in this case I wouldn’t expect them to be complaining about quality… but anyway) And I guess this is the point here. Lack of dedication.

I tried to figure it out, so I started walking around in the landscape and ask people why they don’t write test cases. Here is my top ten answers I collected. Are you ready? Ok, here we go:

  1. I am so smart I can implement this without test driving it
  2. I don’t know how to write tests
  3. This is a really small change, no need for tests
  4. This cannot break anything
  5. I’m in a rush, no time for TDD
  6. I wanted to write tests, but I didn’t 🙂
  7. It’d be too hard to test this mess
  8. TDD’s not a silver bullet. With or without it, doesn’t matter
  9. I’m prototyping
  10. I’ll do the real work, then you can play around with your tests

The sad thing is that I didn’t make up any of these…

I’d like to emphasis this one: “I’m prototyping”. It seems to me that as soon as people get to know about prototyping they get an excuse not to do TDD. Tricky prototyping this is after all. People write a bunch of code, call it a prototype and -guess what- check it in! Ok, first they cross their fingers and say “I hope this works”. So we fall back to Hope Driven Development (thanks for the term, Marcell).

And finally, number ten. I really heard someone say that when I proposed we do test driven development. Some people don’t even consider writing tests real work.

Sadly enough, people who already had the OMG moment seem to forget about tests (I call OMG moment when someone discovers how useful TDD is. Usually it happens when they miss a bug, but their tests catch it for them). One idea we could come up with is a regular TDD group, with the committed ones (this would involve regular meet-ups where we could teach each other tricks, techniques and other stuff. Perhaps after a while everyone will be confident about their skills, so we get several TDD mentors). Maybe we can place them in different  teams so they can “infect” others with TDD (they can insist writing quality code at pairwork sessions). Maybe it helps, maybe not. Any comments welcome.