Fair Housing for Business Rules

I was talking with someone about the reasons javascript is viewed by so many as something to be avoided. He suggested that he didn't want business rules expressed in different places (i.e. the server side code and the client side code). Similarly, in a recent thread on the TDD list it was suggested that stored procedures feel like a code smell because they are black boxes to the application coder and make writing code in an agile way more challenging.

Neither of these were isolated. I hear complaints about both javascript and stored procedures all the time, and for similar reasons: they are hard to maintain and they spread business rules throughout different execution environments.

I think the maintenance issues are more about tools. JSUnit is a wonderful xUnit tool that lets you write unit tests for your javascript and then execute those tests from your ant scripts (if you happen to be using ant). But it has not reached wide acceptance yet probably because of javascript-phobia. Ironic that a potential solution to a problem isn't recognized as such because of the problem itself.

Stored procedures remain difficult to maintain, but that's because vendors haven't recognized the need for tools that can hook into the "units" of a stored procedure so we can unit test them. So we can only really system test them through the exposed entry and exit points. Maybe there are such tools and I just don't know about them. If so, please add a comment below so we can all check them out.

But all of this still leaves open the issue of where to express business rules. We don't want to express them in different execution environments because they become difficult to synchronize. If you're writing a webapp and you want to use client side validation, you probably want to back it up with server side validation. Maybe you're using a tool that does this for you, but you still want to verify that you've configured everything correctly and you still have to synchronize the implementations. Or do you?

In TDD, we talk about requirements being expressed in the tests. Well, aren't business rules requirements? And aren't they therefore expressed in the tests? So what if we could write one test that tested both our server side and client side validation. We do something similar with abstractions in junit already. We write an AbstractWidgetTest and derive ConcreteWidgetATest and ConcreteWidgetBTest to test our classes derived from AbstractWidget. Methods in AbstractWidget are tested in AbstractWidgetTest, and those tests get executed by both derived test classes against the derived application classes.



The problem we face is not that we want to implement solutions in a variety of execution environments. The problem is that we want to test them in the execution environments in which they are written! We test java using JUnit. We test C# using NUnit. We test javascript using JSUnit. Perhaps someone has alredy invented SPUnit ("spoon it"?) for testing stored procedures.

What might be needed here is a language/environment independent testing system in which we can express our business rules all in one place and execute those tests against whatever environments our solutions are being written in. FitNesse accomplishes this at some level, but it doesn't get us all the way there because we lose the beautiful feedback we get from code editors like those in IntelliJ[?], Eclipse and dare I say Visual Studio. If I write a statement in my junit test that calls a method that doesn't exist on another class, I get immediate feedback because code is getting compiled on the fly. Fitnesse isn't capable of this yet. And it would take some doing to write a tool that could give me the same feedback if I were writing a test in java, but testing something in javascript.

In some sense, test-infected code has moved us away from "the best tool for the job" because the definition of "the best tool" has grown from "the most efficient tool" to "the most testable, understandable, maintainable and efficient tool." Having tools that could give us the feedback we have grown accustomed to from xUnit tools while freeing us up to use whatever tools we wish for solutions would open all sorts of new doors for us. Well, maybe just reopening some of the old doors would be a good start.

---

!commentForm