Has unit/integration test without asserts right to exist?

Question

Recently I had to chance to see a bunch of tests without any assert. Those tests had to be accuracy tests.

I think the only thing that can be tested with such tests is to check if none exceptions are raised during execution flow. But anyway I really don't understand how we can verify the accuracy of the code with no asserting tests - even the methods that do nothing can pass such tests.

So I'm wondering what can be purpose of such tests and what else can be tested with that?

Answer 1

Sometimes it is interesting to know that a piece of code may be executed at all.

I do that for (Python) code that produces a graphic output, for instance. I'm happy enough that the graphic gets created at all. When the test fails, I know that something is broken.

Answer 2

Here is an example (C#, NUnit):

[Test]
public void StartUpShutDownDoesntThrow() {
   var aService = new Service();
   aService.StartUp();
   aService.ShutDown();
}

If this test passes it ensures the following:

• The constructor doesn't throw an exception
• Startup() doesn't throw an exception
• ShutDown() doesn't throw an exception

All three items are valuable, maybe even epic. You woud be surprised how many commercial application don't even have something as basic as this as part of their QA process.

So, yes, tests without asserts can have their value, too.

Answer 3

Yes, as @John and @Olivier point out, it's occasionally of value to simply know that some code runs without throwing exceptions (and, I guess it goes without saying, without compile errors). But these are rare occasions, and under no circumstances would I consider these "accuracy" tests.

Answer 4

They could be smoke tests designed to prove something does not throw an exception or something else is throwing doing the work (such as a mock object).

What ever the reason I think you should rename the tests as if people don't know why they exist or what they are testing how can they be fixed if they do break.

Answer 5

I'd let them have the right to exist if they are testing some "legacy code" - code that no one really has a good grip on. No, if they are in there to put on a show of "high code coverage".

It's a first step to getting some confidence in the code. The invisible check is :"no exceptions are thrown". However once you've wrapped up the app in some smoke tests like these, the next step would be to turn the implicit check into an explicit check - put on your thinking cap and come up with observable changes that you can assert from your tests.
You can use tools like TestLint to catch tests like these.

Answer 6

IMHO, tests need to test behavior, not the absence of behavior. If you want to test for exceptions then test for exceptions. Read this blog post. Maybe these tests are tests to get the testing juices flowing, but they shouldn't be there long.

Answer 7

Umh, no!

A test without Assert clearly is a design smell. That's because a good test has to exactly communicate by code WHAT it is testing, and it also has to be trustworthy.

A test of the form

[Test]
public void DoSomethingDoesNotThrow()
{
   var aService = new Service();
   aService.DoSomething();
}

is pointless, even potentially harmful, because it will pass regardless of what aService.DoSomething()` is doing. But the biggest problem is: It doesn't test anything. (And btw: How could this test 'accuracy'?)

It would be better to test some functionality of aService.DoSomething() instead! If such a test passes, you know that no exception occurs, so why then would you need a 'test' like the above anyway?

In general: Always test facts, never the absence of these facts.

Only because it is often done in real world doesn't make it a good practice...

Thomas