Information Technology Reference
In-Depth Information
clickAndWait
Link=Logout
assertTextPresent
Log In
verifyTitle
Integrate Button - Welcome
assertTextPresent
Welcome to The IntegrateButton.com.
Please log in to access exclusive
material for the topic.
As demonstrated in Listing 6-6, Selenium utilizes table models for
testing, which are highly effective communication mechanisms that
someone can author without needing to be a developer. As you can
see, this test does a number of things: It verifies aspects of a page as
well as fills in forms and verifies data.
We need a common understanding that tests are differentiated spe-
cifically by the setup they require (seeding databases, etc.), which cor-
relates directly to how long they take to run. Test categorization is
especially important in the context of CI—when builds run long in too
many contexts, it can drastically affect you and your team's perception
of CI.
Writing and running tests is obviously a good thing, but unless we treat
them as an architectural component that requires proper categorization
and structure, they can start looking like a hurdle, instead of the key, to
success. As the code base increases during your project, we're talking
about
a lot
of tests—and if you run all written tests at all times in your
CI system, builds take longer and longer to complete.
Categorizing developer tests into respective buckets (unit tests,
component tests, system tests, and even functional tests) helps you to
run slower running tests after the faster running tests. For example,
running system tests every time the repository changes is a time- and
resource-consuming task and delays notifying interested parties if
there happens to be an issue with the build. If this delay is too long and
developers have moved on to other activities, one of the primary bene-
fits of Continuous Integration is not realized. Why not run unit tests
every time someone checks code in, as they don't take much time to
