My unit test looks very similar to the class I'm testing. How do I support my stance that the test is, in fact, correct?

Question

I'm working on a boilerplate component that's supposed to generate a working sort-of "getting started" project structure. Think of it, in a web app context, of a component that will generate a Controller, a View and the routes configuration so that once you call it, you can immediately go to the browser, type the route and you'll get the output.

In this boilerplate, one of my class has the responsibility of providing the content of every file it generates (the content of the controller file, the content of the routes file, the content of the views fie, etc).

With such a responsibility, wheareas one method should return the content foo, the test should verify that, in fact, 'foo' is returned.

It ends up looking like this:

// SUT
function getFooFileContent() {
    return 'foo';
}

// test
function testGetFooFileContent() {
    string expected = 'foo';

    string result = sut.getFooFileContent();

    assertEquals(expected, result);
}

The people I'm explaining the reason for this test are new to unit testing, so it's normal for them not to grasp at first sight why is this OK, and have doubts whether this test actually has a value to begin with.

Since I'm in charge of introducing unit testing to my team, I want to explain this backed up by resources that explain this "type" of test in particular, so that I have a solid argument rather than asking them to just accept that kind of test.

PS: For the record, when I started with unit testing (self taught, no mentor sadly), I had the same doubt. In my case I just accepted the test and got to understand its value over the years, when I could finally see the fact that tests are supposed to bind functionality to specifications. It's hard to see that when you're starting.

Update 1:

Due to the fact of my question marked as duplicated for the common should I test a getter/setter? I say:

This is not really a getter and the question is not about whether is worth it or not. The class specification is to provide a template text for a boilerplate. The implementation could very well evolve into having it read the text from a non *.php file, and, in that case, a test would have value as it would bind the specification to the functionality.

The question is how to explain the fact that, even with the current implementation (the one that is just returning a string block) the test itself is correct. I'm specifically asking for resources that backup that argument.

Answer 1

Tests are supposed to have a point.

Never write tests simply because you're supposed to write tests. That's ceremonial thinking. Ceremonies are an excuse to turn off your brain. It's not always better to have tests rather than just code. Sometimes it's worse.

I'm not a TDD hater. I've done it professionally. I wish I never had to work on any project that didn't have well written tests.

But I've seen mandated tests lock code in stone because the tests existed for no better reason than they were supposed to exist. Tests should have a good reason to exist.

Some tests exist to make refactoring easier.
Some tests exist to make adding features easier.
Some tests exist to make debugging easier.
Some tests exist to make conforming to a specification easier.
Some tests exist to make satisfying a customer's needs easier.
Some tests exist to make spotting unintended changes easier.
Some tests exist to make it look like you write tests, just like the cool kids.

So I ask, what is the point of this test?

In your comment:

I thought about forcing a regression bug, but given the fact that the tests I've covered so far are unit, and not integration, I don't see how to explain it to them with mere 'templates'. – Christopher Francisco

you mention regression testing as if it is something only ever done with integration tests and not unit tests. This is not true. In fact regression testing is about the only excuse I can think of to write a test like you've done here. This is a unit test. What would make it also a regression test is running it even when you don't think you've made changes to this unit.

This getFooFileContent() function has trivially simple behavior. I see no logic to test, no corner cases to explore, no potential bugs to uncover. A good testing poster boy this function aint.

A regression test is about the only point I can see here. That begs the question of why you want to regression test this.

A good story to justify a regression test is you want to be alerted if behavior changes. This story is a hard sell to time limited maintenance programmers who want changes to be easier to make not harder. So you sell the point that it makes debugging easier. If somehow the behavior changes it's spotted before you ship.

Well why would that change? I hear your team ask. Because someone changed it of course. Well what if they meant to? What's happening here is changes are becoming expensive because now I can't update this thing without updating it's test. That's a cost and it needs to be justified.

Say someone was scrolling around and without noticing they highlighted a bit of this function, then bumped the space bar and now that bit is gone. This unnoticed change manages to compile and so is about to go out the next time we ship.

Yeah, it's far fetched. But it could happen. If it did, what would it cost?

Well it might bankrupt the company. A bit hard to tell from this example. That's the real problem. You need to tell the story of the test proving it's worth.

Keep in mind that you use source control (you do right?) so nothing has been lost forever. All this is buying you is knowing about the problem sooner rather than later.

A test of trivial behavior comes at a cost. Not testing trivial behavior comes at a cost. Here is where you must find balance. You'll only find that balance when you know why you're writing the test. Make sure you know the story that would make this test useful.

You can try to test everything that could break but I'll settle for writing every test that makes the job easier.

Answer 2

If I were testing a template project generator, then I would not write a test for that getter; what I would do is write a test which runs the entire generator and compares the files it created to a collection of static files which is the expected output. This is entirely sufficient testing for all parts of the generator which have no interesting logic. In cases where there is interesting logic, presumably there will be some kind of input parameters and you will want to write unit tests covering the various parameters, which will not have your “simply repeating the code under test” problem.

Some would argue that this is not a unit test, but an integration test. Well, fair enough, but my perspective is that it is more important that the entire system is usefully tested than that tests of a specific classification exist. Let's consider the advantages of a unit test over an integration test:

1. The test involves less setup and is therefore much faster.
2. It is easier to find the cause of a failure because there is less code under test that could have caused it.
3. It is easier (or possible at all) to test edge cases because you don't have to find a configuration of or input to the entire system which exercises the particular case in a particular class.

In this case, I'm assuming that (1) is unlikely to be a problem, (3) does not apply because the code is trivial, and (2) does not apply because the source of the incorrect string is obvious — if you don't already know that getFooFileContent is involved, just searching the code for the incorrect output string will find the source string literal.

And by doing it this way, refactorings of how the foo file's content is generated that remove/relocate that method don't cause you to have to change the tests, which means that it is easy to see that the change is a pure refactoring since the tests passed before, passed after, and were not modified.