unit testing variable state explicit tests in dynamically typed languages

Question

I have heard that a desirable quality of unit tests is that they test for each scenario independently. I realised whilst writing tests today that when you compare a variable with another value in a statement like:

assertEquals("foo", otherObject.stringFoo);

You are really testing three things:

1. The variable you are testing exists and is within scope.

2. The variable you are testing is the expected type.

3. The variable you are testing's value is what you expect it to be.

Which to me raises the question of whether you should test for each of these implicitly so that a test fail would occur on the specific line that tests for that problem:

assertTrue(stringFoo);
assertTrue(stringFoo.typeOf() == "String");
assertEquals("foo", otherObject.stringFoo);

For example if the variable was an integer instead of a string the test case failure would be on line 2 which would give you more feedback on what went wrong.

Should you test for this kind of thing explicitly or am i overthinking this?

Answer 1

The straight answer is YES, you may still have to. Also, for assertEquals you are essentially checking for two things - types and values, not if they exist. The reason is that the function will show error in an IDE (red line) if one of them is not in the scope. HMMMM.... You can still say that using text editor rather than smart IDEs will not tell you that - which is true. But why wouldn't you use it in the first place? Therefore, that test is automatically done even before you run the test. So, your first assumption about assertEqual test checking for three things is not necessarily correct - It is defenitely two, may be three. Also, when you say about scope, you need to be careful; global or local scope same? What I am trying to say is this:

package bla.bla.bla.SomeObject;

class FooTester{
//Global var "foo"
String fooStr = "foo";

@Test
testFoos_Are_They_In_Same_Scope() {
     SomeObject someObject = new someObject();  // Mock object
     String testFooStr = someObject.stringFoo();
     assertEquals(fooStr, testFooStr);
}
}

Clearly, foo and testFooStr are not in the same scope. fooStr is global and testFooStr is local.

Another good argument for having three separate test is the following:

assertEquals("foo", someObj.stringFoo());

To a person who has never done any programming, this would mean that you are testing for two strings to be equal or not. However, if you have a test where you can say:

/* Asserts if the condition is _NOT_ true
assert("THEY ARE NOT AT THE SAME MEMORY LOCATION, BUT MAY HAVE THE SAME VALUE", "foo" == someObj.stringFoo());

You have to figure out very carefully what you are trying to test and write tests with meaningful names. If you can use one test for three cases, take care when writing them and use some sensible comments declaring test purpose (if necessary).

I have done this in the past and still do it. People criticised me for writing double tests, but never told me that I didn't write enough tests. It pays dividends in long-term.

Answer 2

It depends. Quite probably you shouldn't use three tests for something as small as that, and rather use a debugger if it fails. However, if you have reason to believe one of the 1st two cases would be a probable bug, by all means, put them in, if just as a remainder to check for all of them.