Being Cellfish

Stuff I wished I've found in some blog (and sometimes did)

May, 2009

Change of Address
This blog has moved to
  • Being Cellfish

    Consultant Bestiary


    If you liked the more or less humorus Scrum Bestiary then you might like the Consultant Bestiary. Personally I've been a duck most of the time I worked as a consultant but sometimes a was seal.

  • Being Cellfish

    What is a good variable name?


    You've probably heard a thousand times that a good variable name describes what it is. Some people also thinks that the shorter the scope of the variable, the shorter should the name be. That was maybe true if you write the name out by hand but I think the best (and only) rule of thumb is that the name should be easy to read and describe what it represents. But sometimes it is hard coming up with a good name so what do you do? In the past a did my best to come up with something good but if it is hard to come up with the name, whatever name you come up with will not be that good. But from now on I'll do another thing I read about here. It is embarrassing how obvious the solution is. In TDD you make minimal changes until you have enough code to see the obvious refactorings needed. And the same thing applies to variable names. If it's not obvious at the moment what a variable should be called, just call it something and move on. A few TDD cycles later you'll probably know what a good name for that variable is and you refactor it then. So don't waste time trying to come up with good variable names. Move on and refactor later when it is obvious!

    The good thing about this strategy is that it applies not only to variable names. It works great on all types of names in your code; methods, classes, constants and so on. And yes, I'm assuming you have a refactoring tool that let's you change these names securely and you don't have to do a search and replace that might be a little more dangerous if all your I-don't-know-the-name-yet variables are called "x"...

  • Being Cellfish

    SQL Unit Testing


    Thought it was time to combine my old favorite subject (SQL) with a new interest (TDD). So how do you test drive your SQL? I think the first answer is you don't. The database is typically something you want to fake anyway since setting up and accessing the database is to slow when you want rapid feedback. Nowadays when things like NHibernate are popular I think most people don't write much SQL anyway so there is no need to test drive the creation of SQL queries or stored procedures. But there was a time when many applications kept a lot of logic in the stored procedures and in those systems it might make some sense. Also we have the fact that the database needs to be created some way. Why not test drive the database schema?

    So even though this might not be the hottest topic on the block, what alternatives do we have? First of all we have SQLUnit. This project does not seem to have been updated for several years. Guess that is because we don't put all application logic in stored procedures any more. But it is at least an attempt to create a unit test framework for SQL. But why use the same language for the tests as the implementation? Some people think this is OK but I think there is also a danger in doing so. Switching languages typically makes you do small stupid mistakes you don't do if you stick to one language. But sometimes it might still be worth it. For example I'd much rather use any .Net based unit test framework over SQLUnit and an example of how that looks can be found here.

    Then there is of course the option of not using any framework at all. Creating your own framework may be the most efficient way of doing things and an example of database creation in a test driven manner without any fancy frameworks can be found here.

Page 2 of 2 (13 items) 12