A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
Tonight you will be visited by 3 Ghosts Test Driven Development to show you what will happen if you don't correct the error of your ways...
Actually I agree with a lot of what you said (especially concerning how there is no way to unit test GUI apps properly). However I think having *some* sort of automated testing framework to test different parts of your code is helpful. Again though, if much of your project is not conducive to automated testing (GUIs, GUIs, GUIs), then there isn't much use for this.
I'm not sure what this is referencing, but I don't think it's accurate to say that GUI apps aren't susceptible to unit testing. *Parts* of a GUI app are harder to automate testing for, but if you have a good seperation between GUI presentation and the underlying application and business logic, it should be possible to unit test that seperately.
Then there are tecniques such as mock objects that can help test components such as GUI controls, as well as applications that can act as a 'virtual user' to generate mouse and keyboard events external to an application.
Automated testing is certainly a larger investment with some technologies than it is with others, but it pays dividends in reliable, repeatable validation of existing application functionality and can greatly reduce the turn-around time/cost of a release cycle.
Tuesday, September 28, 2004
For a GUI you seperate it into functional and visual. The test harness has a way to enter/retrieve data and frobnicate controls. Your test would for example set Frank's phone number to 555-1212 and push OK. You would then retrieve Frank's phone number and verify it's 555-1212. Then enter 555-9876 and press cancel, verify it's still 555-1212.
This gets at a large portion of your GUI. What's left is having your harness display something along the lines of "is 555-1212 displayed in the phone number field, 3 pixels from the left edge, vertically centered".
Tuesday, September 28, 2004
If GUI can't be tested so what? The slew of bugs are usually behind the GUI, which definitely need repeatable and automated testcases. Unit testing helps in that. Also, I find unit testing a good opportunity for measuring quality of design (coupling, coherence). XP guys use Unit Tescases as specifications, the things that explain how the code can be used/reused.
Thursday, September 30, 2004
STRIDE by S2 Technologies lets you tap into the interfaces, you can either look at the data, inject your own, or modify it. Their web page bites, but we use it daily and it works fairly well.
What's really nice is we do embedded development, with a PC based simulator we use before the hardware is available. With STRIDE we run the same tests on both platforms, we just go to a config page and select 'RS232' instead of 'some internal windows communications thingie'.
Tuesday, October 05, 2004
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz