Use Case best practice: Test your Use Cases with real data alvin November 12, 2009 - 9:20am

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.

Seven benefits of automated GUI testing alvin June 14, 2017 - 2:47pm
Table of Contents1 - Benefits of automated GUI testing2 - Keys to automated GUI testing and continuous integration3 - Beware automated GUI testing software sales pitches and recorders

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.

How to use ScalaCheck in the SBT console

If you add ScalaCheck to an SBT project like this:

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.)

The Benefits of Pure Functions

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.”

From the book, Masterminds of Programming

Fifty Shades of Mast Cell Disease

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?

Doc: Yes, pee in this cup, and we’ll look at it under a fluorescent light to see if you have the same disease that King George III had.

Me: The crazy one?

Doc: Yes.

Me: Cool.

A collection of ScalaTest BDD examples using FunSpec

Table of Contents1 - Getting started2 - First steps3 - Adding Given/When/Then behavior (and ‘And’)4 - More on Given, When, Then, and And5 - Add more tests within ‘describe’6 - Testing Option/Some/None in a BDD test7 - Nesting describe blocks8 - Using ‘before’ and ‘after’9 - Mark tests as pending10 - Temporarily disabling tests11 - Testing expected exceptions12 - Assertions13 - Using matchers14 - Tagging your BDD tests15 - Other16 - 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.