Ricardo
Ricardo

Reputation: 2943

Does it make any sense to test assertions?

The app source code I have right now (ObjC), sometimes uses NSAssert (like many other program).

I see a unit test that is testing that an assertion is called using XCTAssertThrows.

Is this right from a TDD point of view to test assertions?

Apart from that, if I use the debugger while testing, it stops all the time in those assertions, which is annoying. If I use NS_BLOCK_ASSERTIONS=1 I fix that, but evidently will not work anymore and those test would fail.

Any clue about how to manage that?

Upvotes: 0

Views: 261

Answers (2)

banduki
banduki

Reputation: 27

Forgive me if I am misunderstanding your question; please bear with me.

XCTAssertThrowsError is used to assert that an exception is being thrown. Use it for tests which expect an exception, such as the following:

func test_Divide_GivenADivisorOfZero_ThrowDivideByZeroException() 
{
   let subject = Mathematician()
   // test passes if the exception is thrown; otherwise it fails
   XCTAssertThrowsError(try subject.Divide(5, 0))
}

If I am misunderstading your question, please let me know and I will revise my answer.

Upvotes: 0

MikeJ
MikeJ

Reputation: 2437

If following pure TTD style, you would have a test for the assert, otherwise you wouldn't of written it in the first place - i.e write minimum amount of code to pass the test.

The assert is no doubt in response to an error condition, and by having it you don't want to execute the code after the assert if it's triggered.

Maybe think in these terms to decide - Without a test for it, someone could remove the assert and the build will not break (no test failures), so what would be the consequence of the code being executed after the assert for the error condition?

I would suggest that if you need the assert for a specific reason, then have a test for it.

Upvotes: 1

Related Questions