I never could understand why developers didn’t write tests. The concept of a test is simple. You write a little extra code now that tests the outcome you want or have so that, in the future, when you add a feature or decide to refactor into something simpler or better, you know that you didn’t break anything without having to walk through all the test cases by hand.

There are two approaches to writing tests and one of them is more conducive to test writing then the other.

The first way is to write your application code first then write the tests to back it up. The first problem with this is a matter of motivation really. After writing all the application code and making it work, I find it very hard to motivate myself to write the little extra bit of tests instead of diving right in to the new feature on the roadmap. Why write the tests after you know it works? Well, again, what if you have to wedge a feature in there or refactor? Then you have to recall all the stuff that you tested by hand while you were building it and then test it again, by hand, or write tests at that point and Murphy’s law says that you will forget at least one critical case the second time around.  That is why the second choice is the better.

The second way to develop with tests is to write the tests for the functionality that you want and then write the code to make the tests pass. This is the Agile approach and, in my opinion, the better. Why? Well, you are writing tests based on requirements. So you will know as soon as your code does what you want. Second, you are writing tests based on what you are encountering while writing the application. This lends itself to more coverage because you will be writing tests for all the little edge cases you will encounter while writing the application. This means that, in the future, when you refactor or go muddling around, you can verify, RIGHT THEN, if you broke anything.

I have heard managers complain about developers spending time on tests and not on features first because users and clients won’t see the tests and time should be spent on user/client features. Well, here is the reality, a little time spent at the beginning of a project writing tests saves a lot of time in the end because you don’t need to spend so much time verifying feature requirements while writing. Plus the QA process is much faster and smoother because you are handing of working code from the beginning. Writing tests at the beginning usually saves me more than 10% time on the same project where I write the application code only with no tests! That is 10% faster to release and ensures better user experience in the long run because I verified that the project is doing what it should and handling errors properly before I even wrote the application!

I host some stuff with bluehost and I have to say that I am pretty fed up with them and shared hosting! I know shared hosting is never a good idea but for something as simple as http://isitabugorfeature.com it should be a non-issue. Bluehost has “rails support” but the assholes keep updating gems without letting anyone know and there isn’t a list or anything I can subscribe to that would let me know about these sort of very relevant updates. I have been burned again.

Today someone mentioned to me that bug or feature was down and I logged in and found that, sure enough, they had updated the rails gem. So I changed my gem requirement in my environment.rb file but my app relies on some 2.2.2 specific stuff so it wouldn’t start. So, I am forced to get the rails-2.2.2 tag from github and put it in vendor/rails to get the site back up again. I am so tired of this. I am done with bluehost and shared hosting. I am going to begin migrating everything to my slicehost slices and call it a day.

Goodbye bluehost, I would love to say it was all great but I can’t…