I am not talking about adding minor features to a huge bulk of existing code – in this cases unit tests before code are a great idea, provided that the rest of the code is covered. What I am talking about is relatively large subsystem or independent service which you are designing from scratch.

In this case chance are that however carefully you have designed things on paper, your design is going to change and evolve as you code. You will discover that your assumptions about 3d party systems you have to interface with or components you have to use are wrong. Browser bugs and general weirdness will rear their ugly heads. Your decomposition will have to change. New possibilities for abstraction will become apparent. Certain interfaces will have to be extended, others will prove unnecessary rich. You know the drill.

Well, what happens when you write you unit tests before your code ? You commit to certain decomposition and a set of interfaces. You introduce a bias in your design thinking because at the back of your mind there are all these unit tests that will have to be rewritten, and is it really that harmful to leave these useless methods here (after all they are covered by tests) or do we really need to refactor this common functionality out of this class (after all we would have to write new tests and change existing ones) ?

The other evil of premature unit tests is that you interfaces will be driven by what is convenient for tests and not the intended functionality. Are these classes split for a reason or only so it’s easier to substitute a mock ? Are these setters in the interface necessary or you need to set up the internal state for the test ? More about this in my previous post.

And so you end up with bloated interfaces and a sizable design inertia. Not to mention that any comments by reviewer which would result in a significant change of interfaces or decomposition and therefore trigger a cascade of unit test changes are bound to send you on a quest for best excuses to leave things as they are. My preccccioussss unit tests.

Yet another harmful aspect of premature unit tests is that it wastes the time better spent on flashing out interfaces and finding unforeseen pitfalls and constraints.

I my opinion it is far more beneficent to spend two or three weeks after the initial design coding and prototyping and only when you have the skeleton of the service and major pieces even in sketchy form are in place – turn around and go full blast on unit tests, covering all the code written so far. From that point on write tests together with the code or even before the code.

You can’t just go ahead and do something, no, you must set up you objects, properties, assemble a Rube Goldberg machine of an object tree and then almost as an afterthought give it a gentle push to actually execute something. And so 2 + 2 becomes
MathOperationFactory.getFactory().createOperator(MathOperators.Plus).imbueWithPolicy(new IntegerOperationsPolicy()).appendArgument(2).appendArgument(2).do();

Actually that’s one of the giveaways: when you have a lot of classes with names like “Factory” or “Manager” and methods that start with “imbue”, “decorate” and above all methods like “do”, “run”, “execute”.

For a much better articulated version of this rant, read Steve Yegge’s “Execution in the Kingdom of Nouns”.

One of the big problems with this approach is that it prevents classes for delivering on their encapsulation promise. I mean you can’t tell what a class does anymore because so much of it is determined by other classes with which it has to be assembled to perform anything meaningful.

Sometimes this over-distribution of responsibility is a sign of a bad design, premature and excessive abstraction, attempts to foresee variability points in the code and prepare for eventual changes, which invariably occur not where the original designer carefully prepared their policies and interfaces but in some aspect of the design which requires major tinkering with the code (e.g. instead of ability to read from network stream in addition to file what you actually have to do is make your huge subsystem thread safe).

But lately I have been seeing more and more classes with interfaces bloated for the sake of unit tests.
Classes get more setters, functionality that could be hidden from the outside world in inner classes is publicly exposed, the code is spread around so as to make testing and mocking easier but as mentioned before that means you have to get 10 classes together and tie them with setters in order to get something that can perform a useful operation. And thus you get a fractured facade – instead of acting as a facade that simplifies our comprehension of a behavior whose complex details are hidden in the class implementation we a lot of the complexity manifested in the class interface.

This is where dynamic languages like Javascript shine. Since you can modify objects on the fly and imbue them with additional properties and override or stub out any method – there is no need to put the infrastructure for unit tests in class’s public interface. Interfaces remain simple and focus on what the class is supposed to do.

I have observed a sort of an anti-pattern in object oriented data access layers that treat databases as nothing more than a black-box object persistence store where object graphs are dumped and from which they are reconstituted. You can usually spot this approach if you notice that almost all SELECTs and INSERTs return or affect one record or a scalar.

The nice thing about it is that it allows abstraction of storage and all the interesting processing happens in a pure object oriented universe. The trouble is that it usually leads to abysmal performance since the power of a relational engine lies in dealing with large sets of data and this power remains underutilized when operations that could have been expressed as SQL on the database side are shifted to the data layer code.

The typical example is a code that retrieves ids of all objects required for the operations and then loops over these, reconstituting each object from 5 JOINed tables a record at a time and then iterating over this object graph to perform the operation.

If we but dare to break the abstraction and change the granularity to deal with sets of objects rather than individual objects we can utilize the power of the database to the fullest. This is why I think it wrong in many cases to model nouns as objects and instead propose modeling sets of nouns as objects.

An this brings be to two camps of developers: “object graph” camp and “recordset” camp.

The object graph camp likes to perform all operations on nice object graphs and can’t wait to liberate object state from the messy SQL /recordset persistence (that’s when you also hear “and if we want we could use some other storage rather than database since it’s all so abstracted”).

The recordset camp stays close to the database representation and usually loves data binding features in the UI framework since they allow almost direct propagation of database results and remove all the tedious
“for ” loops that make objects out of records and then loop over objects to populate UI controls.
The trouble with recordset camp is that it does not know where to locate the logic that would normally be present in per-record objects in the object graph case. The anti-pattern here is to stick this logic too close to the UI.

So what logic is usually required ? One kind I would call “checks” that is validations that are performed when something is added or changed in the data set. The other I would call “decorations” – these usually create or update dataset using calculations or obtaining data from sources other than the database (network, user). The common pattern in DB driven apps is: get data from DB, decorate it with calculated and extra-db data, pass it to UI for rendering, get user command+data from UI, check it and add it to the dataset, write to DB.

One approach that I have used rather successfully is to create an object corresponding to a dataset which contains all the required checks and decorations but has no state. All it’s operations are tied to the recordset object in runtime through callbacks (onRecordAdded, onFieldChanged, etc.). The nice thing about this approach is that the object in this case contains all and ONLY the business logic leaving all the data manipulation in the hands of framework supplied dataset object. And we can still use an ability of UI controls to bind directly to the dataset.

This approach may only be good for typical business apps but I think it finds a nice middle ground between the unneeded and slow over-complication of object graphs and a messy databinding-with-logic-in-UI “VisualBasic” approach.

After an hour of debugging InvalidProgramException I finally used usenet to confirm my suspicion – stackalloc is not supported under .NET CF. It will compile but will not work. The workaround is to allocate managed array and then use fixed.

So there I was, trying to give my thread in WinCE a real-time priority, using the trusty old SetThreadPriority which returned success code but failed to give me the real-time behavior what I wanted.  Spent some time making sure that it’s not some silly bug and then more time googling. And to think that I was 2 pages away from it  in the WinCE reference book… Turns out that there a parallel system of setting priorities for threads under WinCE : CeSetThreadPriority.

It allows you to set the “real” real-time priorities from 0 to 255 whereas SetThreadPriority only deals with the lamer range of 248 through 255. It’s also important to know that unlike in Windows, there is no concept of process priority that sets a base for thread priorities. The only thing that matters is a thread priority , be it a thread in devices.exe or you user thread in the app.

Just like in Windows the scheduler implements a priority inversion mechanism where the low priority thread’s priority is temporarily boosted while a higher priority thread waits for it. So if you are writing a thread that needs a really precise real-time behaviour but are afraid that it will interfere with a device driver on which this same thread depends – do not worry: while you thread is waiting on that driver the driver’s thread priority will be boosted.

While playing with all of these I discovered a very informative blog by Sue Loh from WinCE dev. team. Remote Kernel Tracker is worth a special mention a an essential tool for figuring our how your thread scheduling really works.