Hi Rakesh, testing GUIs the way they described is certainly very rigid and can lead to that effect Bob described: you don't change things unless you can't avoid it -- I don't know how much he intended to imply that was the reason for the death of the company mentioned, but it's certainly an implication that popped up in my mind.
I personally like to have my tests separated, being able to test business functionality without the UI (GUI or website or whatever). I've heard this being referred to as the "humble dialog" (you'll have to Google, sorry). It is in my experience also quite feasible to test basic event flows in a UI if you label your UI elements in a suitable fashion. Sequences like "run this action, check that the resulting state has element X disabled" are not that hard to test and tend to reasonably stable over minor UI changes. What Joel was talking about are questions of layout, though. He particularly mentioned layout changes due to different length of text due to font changes or i18n. I personally do not believe you can sensibly test that in a fully automated fashion. A good compromise is to automatically create a folder of screenshots and let someone look through them during QA cycles, but once you start testing pixels the tests get too rigid/brittle. All in all I mostly agreed with Joel (and maybe even Jeff) on that last podcast, which feels a bit weird :-) I like them, but normally I tend to only partially agree with their sentiments. As to the question about the Unix command line: I think the reason Unix GUIs are sometimes bad is that the developers often don't care much. OTOH I consider KDE to be the far better Windows, with a lot of detail and finish that Windows lacks. And there are very awkward Windows GUIs, too -- just look at your average Access frontend or SMB ledger app. In many ways these people care as much about the GUI as the Unix CLI devs, which is not much at all. That doesn't mean you couldn't possibly create a GUI for either of these that's pretty reasonable. Peter On Thu, 2009-02-19 at 10:09 +0000, Rakesh 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 -~----------~----~----~----~------~----~------~--~---
