Comments on: Guidelines for Automated Testing: Defining Test Inputs

By: Artëm Smirnov

Artëm Smirnov — Thu, 27 Dec 2012 18:43:00 +0000

I’ll be happy to read your blog post(s) about those!

By: jmarnold

jmarnold — Thu, 27 Dec 2012 16:08:00 +0000

Artëm Smirnov I think this applicable the *most* in acceptance test scenarios — where you would want to use something like FitNesse or StoryTeller. That being said, I think that the underlying the goal here is simply this: “When I see a failing test, I want to read the test and understand the state of the system, the inputs, and the expected outputs as they relate to the state of the system”.

The “state of the system” isn’t always applicable. In most cases, unit tests are simple state-based assertions on inputs/outputs so it doesn’t make sense there. Data-dependent tests are what typically get you the most. Declarative data for those tests are invaluable for maintenance.

RE: using string conversion techniques
We leverage FubuCore’s model binding pretty hard. We’ll often create a shorthand syntax to make the data more readable/easier to maintain.

I’m happy to blog more about those if you find them helpful

By: Artëm Smirnov

Artëm Smirnov — Sun, 23 Dec 2012 15:44:00 +0000

“Data setup should be declarative” — how exactly do you accomplish it in your tests — is it ST-only, or applicable to all tests, unit and integration? Using test attributes maybe? How do you build object graphs declaratively? I’m intrigued by the idea of “using string conversion techniques” — do you fill up the values from a JSON string? Would make the code simpler, but what about refactoring?

I’m totally into the idea that the inputs belong with your test, but I discovered that often they are worth extracting into their own context class. The name of this class should be clear enough so that we don’t have to look at its code.

The bottom line is, I do put my inputs in the test class, until it’s so much code that you have to scroll through it in order to get to the point.