TL;DR: you are a test/unit fan or you prefer RSpec? It doesn’t matter. You’re testing so you already won.

I guess Fabio Akita got us started with his articles on TestUnit vs. RSpec and CoffeeScript. Daniel shared his opinion on CoffeeScript yesterday because frontend is totally his thing. So let’s talk about testing today.

It’s ugly, man

I’m not going the repeat the whole story. It basically came down to DHH being offended, aesthetically, with RSpec because of the added complexiy. David Chelimsky showed us that it’s about functionality and not about syntax, and Avdi Grimm showed what makesRSpec elegant for him. Until that point the whole discussion didn’t get to anything more substantial than “it’s pretty”. Which is a little sad because it’s doesn’t really do anything anthing good to either. I believe both Test::Unit and RSpec have to be used interchangeably. I’ll explain why.

But my customer doesn’t read my cucumber/rspec features

Please… When you do BDD, your acceptance tests by definition are results of conversations you had with your stakeholders. So, or you communicate with your customers in ruby which I think you don’t, or you don’t communicate at all, which is a problem. BDD is not about using ‘should’ instead of ‘test’. It’s about communication with your customers. (or other dudes, stakeholder can be anyone which has an interest in the project).

The thing is, it doesn’t matter who reads those specs. It matters who writes them and why he writes tehme. Even if your customer doesn’t read them directly, I think if they’re not reflecting his wishes; the project problaby is at risk.

Also. And this is more towards cucumber than rspec. If Ruby was more expressive than plain english; _why would have written Hamlet.

My point is, this is a terrible argument against RSpec. It’s about communication and you can do that with any tool.

For example. We (at objetiva) are currently building an application and it’s sponsor has a pretty strong confidence in what we’re doing. We don’t do any BDD cycles and we do TDD when we need to.

With that I mean, most of the time we’re just building stuff following rails conventions. I don’t think that qualifies as designing. I think TDD is a design tool so when we’re doing plain, ole Rails I think we’re actually, merely doing test first. I think that’s fine because as soon as we step out of anything that isn’t idiomatic rails, we understand and take caution. When we step outside of standard rails CRUD we slow down and take much smaller steps. We use RSpec for that.

I believe that you need to think about your testing. You don’t need to test like 37s. You don’t need to test like thoughtbot and you don’t need to test like pivotal. You need to test like you and you need to think about it again in the context of every project. You need to improve your techniques and you need to judge them in the light of a given situation. Your testing is part of your very own process and is a function of the value you get out of it.

xUnit and its derivatives

Keeping previous section in mind I want to come back to Test::Unit. Even though I prefer RSpec I think Test::Unit is valuable and I try to use it as often as possible; to practice or to write small applications. Why? Because it’s based on xUnit, the original implementation for Smalltalk.

Staying fluid in an xUnit derivative gives you a skill you can apply in quite a few languages. I have actually shipped software in .NET with practically no knowledge, starting with what I knew from xUnit, applying it to NUnit and taking it from there. xUnit based TDD got me to the point where I had and understandable, well factored domain model and .NET events were the only .NET specific technology I had to study to build the 25 line GUI on top of that.

Conclusion

Test::Unit is a valuable tool and you can apply your knowledge about it on a whole lot of languages. If you like the expressiveness of RSpec you might be better off with that. It’s all personal preferences. The only thing I think is important is how you communicate with the folks who are actually going to use your software. Oh, and that you actually test to start with.