In general testing through the GUI:
- is expensive (takes long to write the tests and execution is resource-intensive)
- gives limited insight into the system
- often take only the 'happy paths' into account
- combines multiple aspects in a single test
- is slow and brittle
- needs a lot of maintenance
- is hard to debug
And while unit tests don't suffer from many of these problems, they alone are not sufficient mainly because they:
- give little insight how the components interact with each other
- don't give confidence that the business logic and functionality of the system meets the requirements
Somehow, personally I am disppointed with Part 1 - that aims at explaining philosophies around web application testing in "right" way and ended up in making very generic statements/suggestions like
ResponderEliminar(Looked more like a FAQ about Testing (not even web app testing))
" Explore the system's functionalityIdentify the system's architectureIdentify the interfaces between componentsIdentify dependencies and fault conditionsFor each function:Identify the participating componentsIdentify potential problemsTest in isolation for problemsCreate a 'happy path' test
Invest in integration tests (identify the smallest sub-system)Separation of Concerns (don't do the set-up through the interface you are testing)Test each interface separately (mock out everything that you are not testing)Consider dependencies in production (figure out how dependencies can fail, and test that)
May be articulation was not appropriate ...
Hope to see something really "thought" provoking in Part 2 (in line with what techies normally expect with Google)
Shrini
Interesting. I look forward to seeing more regarding your example application and how to test it.
ResponderEliminarCould you eventually provide a downloadable pdf document as you did with previous posts :) ?
ResponderEliminarThanks
Interesting post, and yes we certainly agree that AJAX web applications can be quite difficult to test.
ResponderEliminarBut the picture you seem to paint is rather bleak, and it need not be.
The situation for testing an AJAX application is actually easier than you may think, provide that you have the right tools and by using their underlying technology base can "do the right things" at the right time.
* To overcome the expense of creating functional tests it makes sense to have a good test recorder, which takes away most of the pain of creating tests.
* Tests can be brittle, so you should have some kind of functional test playback feature than automatically adapts the bahavior of the playback engine to overcome inconsequential changes in the pages tested.
* To split out tests of individual features you need some kind of CallScript capability that lets you organize your tests easily into groups of related functionality.
But you are dealing with AJAX -- and it seems that you left out the most important aspect of all: test synchronization. Tests of AJAX type applications scream out for playback synchronization -- but not by adding Waits or Delays or Sleeps that never work in practice. There has to be a way built into your playback engine to interact with the DOM of the page and sense when it is OK to continue playback.
We believe if you have the right facilities in the test engine the functional testing job for an AJAX application can produce very good results.
When is Part 2 coming ...?
ResponderEliminarWaiting ...
Shrini
It might also be good to mention other test categories as well that relate to this such as: security, performance, etc... I look forward to Part II.
ResponderEliminar