Hm, I just finished a 10.5 year stint in the JavaSE SQE team where one of my focuses was helping the client side SQE team more efficiently test JavaSE's GUI functionality. That means where I'm coming from is not quite the situation you're describing. Rather than testing an application the JavaSE SQE team is testing the platform, and it's immensely more difficult to test a platform due to its generality than it is to test an application.
In any case ... There is wisdom in what they say but at the same time untested code is likely to have a higher bug rate than tested code. Hence it's probably true that an untested GUI will be very buggy except for the bugs that are annoying enough to the users or developers to fix. A lot depends on what they mean by "tests". They might be meaning "tests" to only refer to some kind of automated programmed test case. If so that is a peculiarly narrow definition of "test" as you could have a written test plan which specifies a series of tests that a tester is to manually perform. Those, too, would be tests but would not be an automated test case. If you don't have a defined test plan, then you're left with manual adhoc testing. Adhoc testing only tests what the user thinks to test meaning adhoc testing is likely to miss testing some functionality. Adhoc testing is also nonrepeatable, nonmeasurable, etc. Hence not writing tests for a GUI leaves you with a marginally tested product. They are right that writing automated tests is fragile and leads to a high maintenance overhead, but as I said it's quite possible to have formalized manual tests. I think one must have some kind of regularized testing and test plan if you're going to do a credible job of delivering a software product. The question is simply how to most effectively do the testing. You can of course test all the backend (a.k.a. business logic) code w/ o GUI interactions. That would leave only the GUI layer untested. For the GUI layer itself I believe you just need to realize that GUI testing is a higher overhead business than non-GUI testing. I don't think it's at all correct to say "GUI testing is expensive so therefore you shouldn't do GUI testing" and maybe that's not what they mean. Instead it's better to recognize that "GUI testing takes more resources and requires more effort and sometimes requires rewriting tests". e.g. if you have an API that gets refactored into something the unit tests don't recognize wouldn't you have to rewrite the unit tests? The same holds true for GUI tests. If the GUI changes for legitimate reasons it is analogous to refactoring an API and then results in rewriting GUI tests. - David Herron On Feb 19, 2:09 am, Rakesh <[email protected]> wrote: > Hi guys, > > have you been listening to the spat between Joel Spolsky of > StackOverflow and Uncle Bob? I recommend a listen to podcasts 38 and > 41(http://blog.stackoverflow.com/category/podcasts/). > > Not sure if I was completely convinced they reached a conclusion with > some of the debates. > > Anyway, one interesting dilemma was testing an application via its > gui. Joel made a good point that the tests are fragile and break when > things like menu's move around and confirming things like how things > are displayed is difficult. > > Uncle Bob responded by saying that you shouldn't test the business > functionality through the gui at all and only concentrate on things > like presentation. > > I would really like peoples opinions on this as I'm not sure how > practical that is. Joel (or maybe Joe) says thats how things are done > in the Unix world (write the command line app first then the gui) and > is the reason the gui's suck. > > Is that true? Is it ok to test business functionality via a gui and > live with the problem of fragile tests? Or do you have a way round the > fragile tests problem? > > Cheers > > Rakesh --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
