Quite often when I’m asked to review a UML “Use Case” that someone else has written, I ask “Have you tested your Use Case with real data?” Sadly, the answer is usually “no.”
I don’t know why people don’t do this, but they don’t, and it seems like a very logical thing — essentially a unit test for Use Cases.
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.
libraryDependencies += "org.scalacheck" %% "scalacheck" % "1.13.4" % "test"
it’s only available in the SBT “test” scope. This means that when you start a Scala REPL session inside of SBT with its
console command, the ScalaCheck library won’t be available in that scope.
To use ScalaCheck with the SBT console (REPL), don’t use its
console command — use
test:console instead. A complete example looks like this:
$ sbt > test:console scala> import org.scalacheck.Gen.choose
Note that after you type
test:console your project may be compiled, so that step may take a few moments.
In summary, use SBT’s
console command to start a “normal” Scala REPL inside SBT, and use
test:console to start a REPL that you can run tests inside of. (Note that this same advice also applies to using ScalaTest or specs2.)
When asked, “What are the advantages of writing in a language without side effects?,” Simon Peyton Jones, co-creator of Haskell, replied, “You only have to reason about values and not about state. If you give a function the same input, it’ll give you the same output, every time. This has implications for reasoning, for compiling, for parallelism.”
“Functional programming is often regarded as the best-kept secret of scientific modelers, mathematicians, artificial intelligence researchers, financial institutions, graphic designers, CPU designers, compiler programmers, and telecommunications engineers.”
“If testing costs more than not testing, don’t test.”
~ Kent Beck (via this twitter page)
“Program testing can be used to show the presence of bugs, but never to show their absence.”
~ Edsger Dijkstra
Notes from September 24, 2016:
Doctor: I’d like to collect a bone marrow sample ...
*Al runs out of the hospital in a hospital gown, screaming like a little girl*
(later, after they caught me)
Doctor: The next time you break out in a rash, hives, or blisters, I want you to have those biopsied.
Me: Is there going to be any part of our relationship that doesn’t involve a lot of pain on my part?
Me: The crazy one?
Table of Contents
- Getting started
- First steps
- Adding Given/When/Then behavior (and ‘And’)
- More on Given, When, Then, and And
- Add more tests within ‘describe’
- Testing Option/Some/None in a BDD test
- Nesting describe blocks
- Using ‘before’ and ‘after’
- Mark tests as pending
- Temporarily disabling tests
- Testing expected exceptions
- Using matchers
- Tagging your BDD tests
- More information
This page is very much a work in progress, but it currently shows a small collection of ScalaTest BDD examples. I’ll keep adding more BDD examples as time goes on. Also, in this article I assume that you are familiar/comfortable with Scala and SBT, and are at least slightly familiar with using ScalaTest.