Why might this particular test be useful?

Question

I recently joined a company where they use TDD, but it’s still not clear to me, for example, we have a test:

[TestMethod] public void ShouldReturnGameIsRunning() { var game = new Mock<IGame>(); game.Setup(g => g.IsRunning).Returns(true); Assert.IsTrue(game.Object.IsRunning); } 

What is the purpose of this? As far as I understand, this does not test anything! I say that since he taunts the interface and says return true for IsRunning, it will never return another value ...

Maybe I'm wrong, as everyone says it's good practice, etc. etc. or is this the wrong test?

Answer 1

The test is not valid. Moq is a structure used to mock objects used by the test method. If you tested IsRunning , you can use Mock to provide a specific implementation for the methods that IsRunning depends IsRunning , for example, to run specific execution paths.

People can tell you all day that testing is better at first; you don’t understand that this is actually until you start doing it yourself and understand that you have fewer errors with the code that you wrote first, which will save you and your employees and possibly improve the quality of your code.

Answer 2

This test crowds out the interface and verifies that the interface provides a boolean getter named IsRunning .

This test was probably written before the existence of the interface and probably long before any specific IGame classes IGame . I would suggest that if the project has any maturity, there are other tests that implement the actual implementations and test the behavior for this level and probably use the mockery in a more traditional isolationist context, rather than end the theoretical forms.

The value of these types of tests is that it makes you think about how a form or object will be used. Something like the lines "I don’t know exactly what the game is going to do, but I know that I would like to check if it works ...". Thus, this testing style is more suitable for making design decisions, as well as for verifying behavior.

Not the most valuable test on the planet, but serves its purpose, in my opinion.

Edit: I was on the train last night when I was typing this, but I wanted to refer to Andrew Whitaker's comment directly in response.

It can be argued that signatures in the interface itself are sufficient to secure the required contract. However, it really depends on how you relate to your interfaces and ultimately how you test the system that you are trying to test.

There may be a tangible value, explicitly indicating this functionality as a test. You explicitly verify that this is the desired functionality for IGame .

Let's take an example of usage, say that as a designer you know that you want to show a public getter for IsRunning to add it to the interface. But let's say that another developer gets this and sees the property, but does not see any of its applications elsewhere in the code, we can assume that he has the right to delete (or remove code rot, which is usually good) without harm. However, the existence of this test clearly indicates that this property must exist.

Without this test, the developer could change the interface, abandon the implementation, and the project will still compile and run, it would seem, correctly. And that would be much later when someone might notice that the interface has been changed.

With this test, even if it looks like nobody is using it, your test suite will not work. The actually documenting nature of the test tells you that ShouldReturnGameIsRunning() , which at least should spawn a conversation if IGame should really expose an IsRunning getter.

Answer 3

Perhaps the test has been written (before) the code, which is good practice.

Equally, it may be that this is a meaningless test created by a tool.

Answer 4

Another possibility is that the code was written by someone who at that time did not understand how to use this particular fake framework, and wrote one or more simple tests to learn. Kent Beck talked about such an "educational test" in his original TDD book.

Answer 5

This test could make sense in the past. This may be a test of a particular class. It could test abstract, because sometimes it makes sense to make fun of the abstract class that you want to test. I see how a (less informed (like me)) follower of the TDD way of doing something can leave a little mess like this. Clearing dead code and dead test code is really not suitable for the red, green, refactoring natural workflow (since it does not break any tests!). However, the story is not an excuse for a test that confuses nothing but confuses the reader. So, be a good scout and remove it.

Answer 6

In my honest opponent, this is just rubbish, it only proves that moq is working as expected