Meta Bates

Five years ago I left the world of contracting and reentered the world of the full time employee, and I enjoyed every minute of it (well, almost). Now fast forward five years and I find myself once again at a crossroads. Do I continue on as an FTE or do I become a contractor, and play the field, so to speak? Looks like I’m going to go with the hired gun route for a little while, but that’s not really the point of this post.

During the past week or so I’ve spoken with many great companies and people. I’ve been fortunate enough to have a high degree of interest in what I can bring to the table. During those discussions I talked with a really nice guy at a what seems to be a really cool company, I won’t name names, because this isn’t about either the person or the company, but rather something the engineer said during our phone conversation that got me to thinking.

“We don’t have any tests because I couldn’t convince the company to allocate the time for them.” That statement really hung with me. After I got off the phone I started thinking really hard about that statement, and all I could think of was how testing is not an option and people shouldn’t need to be convinced to have time allocated to them.

As developers it is our responsibility to insist on testing. Always include testing in your time estimates. Never give the client (or your company) an option that includes a time estimate without testing. If a feature takes 2 days to code and a day to write tests, then your estimate is 3 days, never 2. You should never say, “Well, I can get it done in two days if I don’t write any tests.” That’s just an unacceptable thing to say. What you should be saying is, “That feature will take three days to code”.

I don’t feel I should sit here and tell you all the reasons why you should test, you should know them already, and frankly, they’re all very obvious! But, if you need a few bullet points to ‘convince’ your client, here are a few:

• Less bugs – The more tests you have the less bugs you will have. It’s just a fact. You won’t have 100% bug free code, that’s a nearly impossible goal, but you highly reduce the likely hood that as soon as you get your code into production your users will find all the breaking points of your code.
• Better maintainability, means faster feature turn around – When you have a large test suite it means adding, updating, or even removing features because a whole lot easier, which means it SAVES time! Why? Simple, you don’t have to go through and manually test every aspect of your code to make sure you didn’t break something elsewhere by adding that validation, or by refactoring that bit of code, etc… That translates into real $ savings.
• Test driven development saves time – this isn’t quite the same as my last bullet point. Imagine, if you will, you are writing a four step wizard in your application. If you write a few test scripts using something like Cucumber first before you write your code you can simply keep re-running those to make sure your code is working. If you don’t have those test scripts written then you continually have to keep going to a browser and entering all the information in each of the steps so you can test something in step four. Which one do you think takes longer, having a few test scripts you can run, or manually going through the four page wizard each time you make a change?
• It’s an investment – thinking of having test scripts like owning a house. When you don’t have tests and you just keep testing in the browser or the command line what you are doing is a kin to “renting”. There is money being spent, but at the end of the day you have nothing to show for it. You’ve spent hours “testing”, but tomorrow when you come in you have to do it all over again. When you spend those hours writing tests you are actually “buying” something. You have something to show for that time and money you’ve spent. Tomorrow, next week, next month, next year, those scripts will still be there, they’ll still be working for you, giving  you a return on your investment.

Well, I hope I have hopefully made a case to you the engineer as to why you should insist on testing. It’s the right thing to do, for you, for your application and for you client. If if anyone tries to give you grief about it, send them my way, I’ll sort em out!

Now that I’m back on track with DataMapper, I’ve got migration support for both it and ActiveRecord just about done. In addition to the actual rake task, db:migrate (btw), I had to set up a good way to test rake tasks, something I’ll share at a later date, but needless to say it’s included with Mack. I also had to deal with the pain in the ass-ness of dealing with two VERY different ORMs, in the same test system! Let me tell you, that sucked!

Good news is that things seem to be working, at least going in the ‘up’ direction anyway. I still need to write the ‘down’ direction revert stuff. Hopefully, that shouldn’t take too long now that I have a good way of testing the task and the migration stuff.

Unfortunately, I feel as though as soon as I release this stuff, which should be by the end of this weekend, DataMapper 0.9.0 will be out, and I’ll have to re-write most of the DataMapper stuff because the API is changing so radically. I guess I’ll just have to deal with that when the time comes.

In the meantime I’ll let y’all know when migrations are done and out there in the wild.

I’ve been asked by people why I’m not using spec tests to test Mack. I’m currently using just plain old regular unit tests for my tests. It’s a good question, but not really a valid one, I think. Should it matter what type of tests I’m using as long as I’m testing? Tests are tests. The framework you use to do your tests is moot as long as the tests you write are good, solid tests.

I jumped on the spec test bandwagon about a year or so ago. I forced my whole team to start writing in nothing but spec tests. The team, is still not impressed. If I were to tell them we weren’t using spec tests anymore, they would be EXTREMELY happy with that.Spec tests are certainly prettier than ‘regular’ tests. I’ll give you that. They are more ‘human readable’. With that said I find assert_equal to be fairly easy to read.

So why do I use regular tests, and not spec tests? A couple of reasons. First, they’re there and built right in to Ruby, ready to go, no new gems or syntax to learn. They’re fast. They are faster than spec tests. I see it everyday at work. I can also, and this one is HUGE, run just a single test or a regex’d series of tests. I really love that last bit. I have yet to find a way to do that, easily, with spec tests.

Again, how people write tests doesn’t really matter so much to me, it’s just that they write them. Testing is too easy in Ruby, there’s just no reason for not writing them.

On the heels of yesterdays release of 0.4.0, there is a new release today, 0.4.1. Although this is not a sexy release, as 0.4.0 was, this is an important release.

What makes this release so important is that it fixes, adds, or improves testing support for Mack applications.

The implementation of some of the testing stuff has changed under the covers, but it’s the new stuff that is really important. let’s take a look at some of the stuff:

• assigns(key) – This one should be familiar to all you Rails folks out there. This allows you to get an instance variable that was set in a controller, and access it in your test.

  def test_something
    get foo_index_url
    assert_not_nil assigns(:foo_list)
  end

• in_session – This methods allows you to wrap a block in the context of a session. This is great if you’re trying to do integration testing.
• set_cookie, remove_cookie – These methods allow you to either set or a remove a cookie in your tests. Great if you want to test an action that reads a cookie, or test to see what happens if you set a cookie, then remove the cookie and call something else. Also great to use with the in_session method.

There are a few other hidden treats in there, but those are some of the highlights. These things help bring Mack testing to a usable level.

The Mack Demo Blog application has been updated to demonstrate some these things. You can pull the demo using Git here: git://github.com/markbates/mack_blog_demo.git

Changelog:

• Improved testing support.

• Added assigns support to testing. This is allows for pulling instance variables that were set in a controller to tests.

• Added ability to do ‘session’ based tests.

• Added assert_difference method.

• Added ability to set/remove cookies before requests are made.

• gem: mack_ruby_core_extensions 0.1.4

$ sudo gem install mack