A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I am working on a complex business application with many libraries and layers. From a users perspective, they complete a form, hit save, and a couple of seconds later a new row item appears in a datagridview. Underneath the hood there are webservice calls, message bus lookups, calculations, db persistance etc.
The QA team are using a UI automation tool to test the UI by simulating a user filling in the form and then interrogating the datagridview. We've had mixed results with this because there is a delay between saving the data and it appearing on the view - a delay that is outside of the applications control. Also, to me, as a developer, this doesn't seem 'tight' enough. It seems to be prone to error, especially if a piece of UI changes. It also doesn't seem the correct way to test if a piece of data has a certain value in a view after saving a business object.
The UI layer is light, all business logic is inside domain objects. I am considering proposing that we use a some sort of testing framework that works and just below the UI layer, but above everything else that will essentially do the same test as the QA tool (except for usability). But I read that unit testing is not meant for complex business flows such as this, but for public methods on class.
Does anyone have experience testing these kinds of flows? Is a unit testing framework suitable (it's just code one way or another)?
Any insights appreciated.
It seems to be widely (though not universally) held that automated testing of UI's is difficult and in many cases not worth the effort. Automated testing of non-UI modules should be realistic. So your solution sounds correct.
As for real experience, I played around with automated UI testing using a couple of the widely available tools and it was pretty excruciating. Like a lot of things, for trivial cases it was fun and easy but anything remotely complicated, which of course is where we want to focus our QA effort, quickly became bogged down to the point where it continues to be much more efficient to just have a human do it without the benefit of a tool.
+1 Mike S.
There's also dbunit for setting the database contents to known states before testing and httpunit and htmlunit for UI test creation. These WILL allow you to test the UI (delays and all), but will be more work than a record and playback type tool (like Selenium).
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz