Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have a tool that is going to be run as part of commit stage on Continuous Integration server to check whether all unit tests run do have an assert. Its main purpose is to eliminate silly mistakes like using Equals method that just returns bool instead of ShouldEqual assertion method.

But there are sometimes cases when tests are intentionally (or at least semi-intentionally) written without asserts - with an assumption that if the code doesn't throw, the test should pass. I'd argue about readability and explicness of that kind of tests, but there are some suites that do this all the time.

I'd like to have a possibility to mark that kind of tests with special attribute, so that if someone really wants to have a test without explicit assertion, he would at least need to say it explicitly.

I'm wondering what would be a good name for such an attribute. My two (fairly different) ideas by now are:

  • [SmokeTest] - as "passes when no exception thrown" kind of tests is only looking for smoke and not testing any outcome, this name sounds right, and it also suggests that this is not a full-fledged unit test - as is my intent,
  • [ExpectedNoException] - this one is much more obvious in its meaning and corresponds pretty well with standard [ExpectedException] attribute provided by some of the most popular .NET unit testing tools.

Or maybe it would be the best to have both possibilities? But the result of both will be exactly the same, so it can be confusing which one to use.

As naming things is one of the hardest thing in Computer Science, I hope for some good suggestions.

EDIT

First answers suggest adding try-catch and Assert.Fail in catch. This would do the trick, right, but somehow I feel that an obligation to add meaningless code just to satisfy the build process is a bit smelly. The attribute is not much different, but I treat it more as "metadata" than the code. At least this is my personal opinion - you could disagree and I will be grateful for saying this, too :)

What I seek for is not a way to have a dummy assert in each test, I'm looking more for the generic term I could call that kind of tests.

share|improve this question

closed as not constructive by Graham Lee, ChrisF Jan 20 '13 at 12:26

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

    
The appropriate answer to "what should I call <X>" for any <X> in your team's code is whatever your team will readily understand. –  user4051 Jan 20 '13 at 12:08
    
Do you really have enough of a problem with people accidentally writing unit tests with no asserts, that you need to force them to jump through an additional hoop to deliberately do so? –  Carson63000 Jan 21 '13 at 0:19
add comment

2 Answers

Do you count a call to fail() as an assert? If so, you could put an explicit call to fail in the catch block of a try-catch containing all code for the test. Then all tests could have at least a call to assert or fail.

share|improve this answer
add comment

You could assert that it does not throw.

try{
  mycodesnippet
  assert -> pass
}catch{
  assert -> fail(reason);
}

Wrap this to look nice in your test suite and programming language.

You should be good to go.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.