Introduction: I first wrote this article about automated GUI testing many years ago, but I find that it still holds today.
I just wrote most of the following note on the Apple Mac Java-dev mailing list, and I'd like to share it here as well, because I think it captures my thoughts on the benefits of automated GUI testing and GUI testing software.
I ran automated GUI tests part-time (4-6 hours per week) on a project with 8-12 developers, and saw some good benefits. True, in the 80/20 rule, 80% of the problems were due to UI changes and communication, like “We forgot to tell you we split the Name field into First Name and Last Name,” but with a good automated GUI testing tool, one test may fail, but the rest of the automated GUI test suite keeps running (see Fowler’s continuous integration). Furthermore, with a good GUI testing tool, something like this is also a minor change to get the test running again.
Writing custom generators for ScalaCheck can be one of the more difficult and/or time-consuming parts of using it. As a result I thought I’d start putting together a list of generators that I have written or seen elsewhere. Unfortunately I can’t credit all the ones I’ve seen in other places because I google’d and copied them many moons ago, but I’ll give credit/attribution to all the ones I can.Back to top
This is a combination of generators I wrote, and some that I copied from other places and may have modified a little:
Some long time ago I was working on a large software development project, and I wasn’t happy with either the quality or the velocity of our programming effort. So one night I sat down and tried to work out an activity diagram to show what our software development process needed to be, to improve both speed and quality. It turns out that a lot of this is just common sense, but for some reason or another team members would try to circumvent the process, which always led to more pain for everyone involved.
As a business analyst (or any person interested in writing software requirements and quality), there is one thing you should always ask yourself whenever you write a business requirement:
Is this software requirement testable?
I’ve seen some business analysts write some crazy things and call them requirements, but IMHO, if you can’t test it, it’s not a requirement.
A QA Engineer walks into a bar ... (image from this link).
I was reading a book recently and I ran across the following quote, which I think comes from Bruce Tate:
Think of a unit test as another client of your application.
That resonates for me on many levels, and it's a great way to think about test code. I also like the following quote, but that may be because I said it:
I know this code is wrong because I can't test it.
Yours in unit testing. ;)
One Java programming "best practice" that has been strongly reinforced for me during the last several weeks is making sure you have a declared interface that defines the behavior (signature) of your Dao (data access objects) classes.
Automated GUI testing tools FAQ: I've read that you've done a lot of work with automated GUI testing tools, can you share some "lessons learned" about your automated GUI testing tools experience?
I'll come back and update this article from time to time as I run into more "lessons learned", but after writing my last article (Seven benefits of automated GUI testing), I also wanted to share these ideas on "Automated GUI testing best practices."
Yesterday I created a short YouTube video demonstration of "GUI regression tests" against the Google Chrome browser, using my Agile GUI Testing software. This video is a little more than two minutes long, and demonstrates some simple GUI regression tests on the Chrome browser, in the format of a presentation.
As mentioned, the Chrome browser tests shown in that video are completely automated, using my Agile GUI Testing software (AGT).