First API, then GUI
This post is a dump of my "stream of conscious" (or to put it differently - my emotional mumblings) about the way we waste our time writing clickable GUI tools to run testing scenarios so we can verify the correctness of the software we write.
The Story so Far
Ok, the story goes like this (10,000 feet view): we have our super-hiper-duper sophisticated system which does some magic with incoming web requests. At some point we started to receive traffic from some partners (3rd party systems). Each of them uses slightly different parameters and expects slightly different response. Normal stuff, right? Yeah, normal stuff.
So at some point we decided it would be cool to have a small, simple GUI tool which would simulate the incoming traffic. You run it, click "partner X", click "single random request" and it sends a request (mimicking what partner X does) and then you look at the logs to find out what happened, and whether it is OK or not. Then you click "partner Y" followed by click on "500 requests per second" and voila! - you have just simulated DoS by partner Y! ;)
So far so good, but...
Damn it, Damn it, Damn it!
Two things that I hate about it. First, this is a form of manual testing. You run something (by clicking ugly gray Swing interface - yuck!), and then you spent time looking at all these logs and trying to figure out what happened there. Oh my, what a waste of time!
Second, this is not flexible enough! Creation of GUI takes time (Swing experts, where art thou?) and we already feel we need much more than what our current GUI offer, but we have not time to implement it (hint: we suck at Swing development, at least I do!).
If Only I Had Been Smarter Back Then...
So what should have been done in the first place? Of course, we should have invested in some nice API, not in GUI!
What would be really cool is to have API like this (it would be more complex, but you get the idea; and BTW. this is much better than configuring things via Spring XML files because of flexibility):
Traffic traffic = new TrafficBuilder()
TrafficStatistics stats = traffic.goJohnyGo();
// here stats tells us about avg time, number of failed requests, etc.
This is a great start for writing tests! Tests which measure success rate of our responses, response time, memory consumption or any-other-fancy-thing that we care about.
And then what?
Once you have your beautiful DSL API you can actually start using it. What I plan to have is to run it with some Groovy scripts. That should be pretty usable. First create a "fat jar", and then run it with Groovy. This gives me both the pleasure of using DSL API and the dynamic/flexibility I need.
Back to our Project
The situation we have right now is not so bad, because the code is quite good, and it is not a problem to divide the application into backend (real things) and frontend (Swing GUI). Then we can add another module/package for DSL to make the backend usable. Later on we can write functional and performance tests on top of it. However, I feel that the implementation of the GUI was a waste of time, and a dead end - we can not really progress with it, and it does only a fraction of what we require now.
Thing to Remember
The rule of thumb here is to first create nice, reusable API, then use it programmatically, and then - when you have nothing better to do - create a fancy GUI.
Now that I write these words it all seems so obvious. What a pity it hadn't been so two weeks ago! :)