testing

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.

How to use ScalaCheck in the SBT REPL (command line)

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

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.

One thing a business analyst should ask about any requirement

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.

Fifty Shades of Mast Cell Disease

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.

Software bugs help doom Japanese black hole satellite

In another example of a high-profile software quality problem, Gizmodo reports that a Japanese satellite that was meant to observe black holes was doomed by poor software quality:

“It was only up there a month when something went wrong. A series of unfortunate events caused by both human errors and software flaws sent the satellite spinning out of control.”

fMRI software bugs upend years of research

I’ve seen several articles about major software bugs (and a lack of testing) recently, and one of them is related to MRI/fMRI image processing. From this article at theregister.co.uk:

When you see a claim that “scientists know when you're about to move an arm: these images prove it”, they're interpreting what they're told by the statistical software.

A whole pile of “this is how your brain looks like” fMRI-based science has been potentially invalidated because someone finally got around to checking the data.