Using Unit Testing to shortcut UI usage, does anyone else do this?

Question

Background

I admit, I don't use unit testing properly. I'm working on a monolithic Windows Forms application, and it was never written with Unit Testing in mind.

However, for the last 18 months or so, all my code has been written in a significantly more compartmentalised (read: good) manner. I have a Unit Testing class configured and it does a lot of complex wireup to simulate the user launching the software. It can spawn off forms and do all sorts of things. It's a bit like a mechanism to script our software usage.

Instant results

Another thing I use it for (more and more often now) is to shortcut usage of the software altogether. F5 + running, plus navigating my way though the system (in the last 5 years, I've really gotten used to it) takes a lot of time.

My latest addition generates reports, it does all sorts of complex grouping and analysis. To test this, I've got a unit test which calls the code and spits out the results with TestContext.WriteLine() . It works extremely well, being able to right click the test and see results instantly. This is before I've bothered to mock up a UI for the functions yet.

Futhermore because the test scripts don't impact the final software, I am free to fire in data from different sources and manipulate it to make better tests.

Pointless

When people write code and they're serious about testing (usually a demo or something), they'll write a test that asserts x = y + 1 or something ridiculously simple. I need to check that massive hierarchies of data have grouped and sorted. Perhaps my text based output is enough, and this can be compared against an XML/text document in the future.

Am I for real? (yes).

Do you use unit testing this way? I find it very useful, but I sometimes feel it's the wrong way to use them. As a general scriptable framework for the project, it's invaluable.

Thanks, Tom

PS Please don't think less of me because I might be abusing the system...

Update

This is a broad question, the answer is spread over two answers, so I'll mark the first one. I assume this is ok.

Answer 1

Your question is fairly broad, but I did pick up on one thing I'll just expound on, in hopes that it helps.

One of the fundamentals of Unit testing is that you are testing a single expectation of a single operation in each test. The general upshot of that is that a single test should only have a single Assert in it, and it should be fairly 'simple'.

A single public method of a class in your application likely would be touched by multiple tests. Each of those tests will assert that something expected happens as it should, given certain input.

The point of having the tests so narrowly focused is so that when you (inevitably) break a method accidentally when refactoring, or changing some underlying code, your failed test will give you a very clear idea of what is going wrong.

Trying to test a complex series of expectations at once (in one test) reduces/removes that benefit.

Also keep in mind that just because you have 'massive hierarchies' does not mean your tests will be horribly more complex, individually. It does probably mean you will have many more tests, though. But ultimately, a test isn't much more complex because you expect 10,000 results each containing X, Y or Z - or just 10.

Answer 2

While I think your approach of building a testing harness and doing forms of automated UI testing is useful it is very much NOT a "unit test"

There are several software packages out there that will simulate UI usage and even do some level of tracking, building your own that suits your needs seems fine to me. But I would caution that you don't confuse this with unit testing.

As Andrew said unit testing is all about testing small pieces of functionality in simplistic tests. Your example of x = y + 1 is oversimplified. The goal of unit testing, IMO, is to develop a suite of "baseline" tests that will verify that your assumptions you made 6 months ago about how some method works still holds true today.

When your unit tests become so large and complicated that they become a maintenance task in their own right then you have missed the whole point. "You're doing it all wrong" as they say.

Given your description of what you built it sounds like you have built a whole other program that you will have to deal with. If you happen to introduce a bug in this new testing system you will generate bad data and that could cause you to hunt down bugs that don't actually exist.

With a unit test you purposely want to keep them short and simple to avoid this problem. If your unit tests become unwieldy they become a chore. When they become a chore they start to get ignored and at that point you have lost the battle.