A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I've finally begun learning about test driven development and a recent thread here got me thinking about refactoring a swing app I'm working on to use automated unit tests....
Trouble is, I can't find a single example of a TDD-oriented Swing app. Anyone know where I can find some sample code to look at?
Taking a step back, I'll also ask...Is this a waste of time? The event-driven nature of Swing seems to make it extremely hard to separate logic and UI. And looking at tools like jfcUnit, which seems to be capable of interacting with swing gui objects directly, I wonder whether separating logic and UI even gets you all that much in terms of testability???
It's tough. If you separate everything using the MVC paradigm you'll at least be able to test the model (and possibly the controller).
I had a look at JFC unit but found it be incredibly clunky. There is also something called Abbot but it didn't grab me either. http://abbot.sourceforge.net/
It would be interesting to hear views from others on the topic.
Wednesday, November 10, 2004
GUIs don't really lend themselves to test-driven development. I do a lot of work with Swing, and what I tend to do is to keep the business logic very separate to the UI code, and run unit tests on the business logic - but only when it makes sense.
Most GUI bugs come from things like aesthetic issues (layout isn't right) or a threading issue. Since those are non-deterministic, you can't really use unit testing to find those.
Unit testing is useful for things like validators (that validate the input the user puts in a text box), the model, and the like.
I second the MVC approach, keep all your logic separate and test that.
It is almost impossible to automatically test GUIs :-(
anon in iceland
Thursday, November 11, 2004
It's my impression is that the TDD approach benefits design more than testing. The exercise of writing test cases against a design/spec helps flush out flaws in the design. While TDD won't necessarily find syntax flaws, it can provide those "why didn't we think of that" moments.
Monday, November 29, 2004
Sorry - I ran off before finishing my thought.
My point was that writing test cases against a spec (before coding) would be benefitial with Swing since the excercise itself would help one think of "what-if" scenarios.
Now, perhaps my understanding of TDD is fuzzy. It sounds like you guys are talking about writing code in such a manner that it can be hooked into a unit testing framework. Hmmm....
Tuesday, November 30, 2004
Right, TDD refers to *automated* tests written during the coding process.
I've tried several times to tackle this problem, and to be honest it's just really hard. One design approach (other than the obvious MVC, separation of presentation and logic, yada, yada...) is to create "commands" that can be directly invoked from the GUI, but that do all the work (and can thus be tested separately). This is something that Word Processors, IDEs, etc. seem to do a lot of, which in turn makes scripting them easy.
I agree with the other posters that unit testing GUIs is just plain hard. You can unit test just behind the UI, especially with Web applications, but with Swing, this has to be planned in advance.
Maybe the way to think about it is that TDD for Swing is basically thinking hard about how to design your software and interactions so that very little is left in the UI to test other than layout and basic wiring.
A good article on this is:
Tuesday, November 30, 2004
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz