The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

verket (34) [Avatar] Offline
#1
- Gain trust with UI tests: I imagine a good reason to do UI tests, is that you have functionallity on the client. e.g. we have a web app that allows the user to sort a table, client-side. The only way to test this java-script, is with a browser. (we did just that, with Selenium)
- Automate along system boundaries: I guess you're talking about what technical staff call "stubs": replace an external system by something that you do have under control, and can predict the results of. This really needs a graph.
- Automate below the skin of the (Web) application: "not running a browser allows automated checks to execute in parallel". I agree that this is true, most of the times. We have a website that we wanted to test concurrent users on, but because the data of the user was saved in a cookie, and you can only have one cookie, that was constantly being overwritten, this was not an option. To this day we have no workaround. (Although, we could create a stub for this cookie, couldn't we?)
- try this: specify UI functionality at a higher level of abstraction: it would be great to have an example of a bad and a good test.
The same goes for the paragraph "we went through the predictable path of...". Add concrete examples and it becomes a lot more interesting to read.