I love automated unit tests - part II

We recently reached the milestone of being feature complete in the web interface for Timeless 3.0. The next step was to create the installation so we could start our in house alpha testing during the development of the Windows version. But since we allow the choice of Access as a database option for small teams using the Windows version, we felt it was best to create the database and verify our business layer worked before integrating the SQL scripts into the web installation.

If you've ever developed an application to work with SQL Server and MS Access, you know there are differences. There are slight SQL differences, but the big one for us was differences in the way they handled paramertized queries. SQL Server uses named parameters and does not care about the order while the OLEDB provider for Jet only cares about the order of the parameters. As you can imagine this can cause significant testing.

Thankfully, our automated unit tests solved this problem. We still had to make the code changes, but it was a lot easier than trying to change it during UI development. It also meant we wouldn't be making changes to the web version during alpha testing just to accomodate Access in our Windows version.

As a side note, our test suite executes around 40,000 commands against SQL Server and around 42000 against MS Access.

I love automated unit tests

Did I mention that I am a big fan of automated unit tests?

As we develop Timeless Time & Expense 3.0, we are anticipating many things we would like to do. Some of these will not be available on 3.0 release date. Some are not even definate, but we are preparing for them now. One such item is a hosted version of Timeless Time & Expense.

Unfortunately, we put this off a little too long. We really should have done it months ago, but somehow other 3.0 development took priority. The key to a hosted version is running many organizations in the same database. This means adding another key field on nearly 60 tables. Were it only that simple......

Adding a new key field means a change to every foreign key and every data access call. Even that isn't so bad. The real problem is testing it. That is where a suite of automated unit tests help a ton. When developing the original web version, we created automated unit tests for all database and business logic. During the 3.0 development we expanded the tests for all new functionality. So even though we started this a little late in the project, it only took a week and a half to implement and test. Without already established unit test, this would likely have set the project back months.

An additional challenge was making sure the new logic really did only access one organization. After all, when your application only works with one organization at a time, how could your be sure it wasn't crossing the line somewhere? In new development, this wouldn't be such a concern. But when the change is to an established application it is a scary and daunting prospect.

Again, automated unit tests come to the rescue. With unit tests, we can simulate things that would take months to test through the UI. Only the last half week was spent adding the new unit tests. With that small time investment, we can be confident we can deliver a hosted version plus be ready for the next big change.