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.
