should asserts remain in the testing version

Question

The topic of using asserts during development is widely covered on SO. The code has three conditions:

1) Development
2) Testing
3) Production

Asserts are present in the development version and are removed from production version. But I've found anything that says they should they remain or be removed in the testing version? Any thooughts?

It depends on whether you want to test the code that you're planning to ship or some other code. Different isn't the same. — Pete Becker, Oct 23 '13 at 14:55
@PeteBecker, can you please elaborate on your comment? And do you use assertions? — Max Koretskyi, Oct 23 '13 at 14:57
If you're going to ship with asserts removed then you must test with asserts removed. Otherwise you're not testing what you're going to ship. — Pete Becker, Oct 23 '13 at 15:59

score 3 · Accepted Answer · answered Oct 23 '13 at 14:16

3

Opinion: if you break up testing:

function testing (asserts remain)
unit/integration/system testing (asserts remain)
release/acceptance testing (no asserts; you test production-ready code)

answered Oct 23 '13 at 14:16

mark

5,269
2
21
34

score 2 · Answer 2 · answered Oct 23 '13 at 14:24

2

I never write asserts. Instead, I do Unit Testing and Integration Testing etc against real production code.

I don't like using assert because their ability to detect problems are somewhat limited, and I'm paranoid about unintended side effects.

I very much don't like having conditionals in the code which compile certain things in or out depending on build flags such as Development vs Production. These conditionals only serve to complicate the code, and they have to potential to make it so that the code that you test is not the same as the code in production.

Personally my feeling is that the only code that should be written in the actual business module is production-level code, and all testing should be done against that. No changes should ever be made to the business model for the purposes of testing. ie, if you want to test something, make it public and write an external test for it.

answered Oct 23 '13 at 14:24

John Dibling

99,718
31
186
324

Can't agree more on avoiding conditional debug code mixed with production code. Just the other day I made an exception to this rule out of urgency and this bit me hard: the debugging code had subtle, unintended side effects so what I tested (with debug code enabled) was bug-free but the actual production code had *new* bugs. – syam Oct 23 '13 at 14:39
@syam, asserts should be removed from production version. And asserts should not contain any logic that may affect application when asserts are removed. – Max Koretskyi Oct 23 '13 at 14:50
John, thanks for your answer. I don't have much experience with asserts but most people agree they should be used. Code Complete says that they should be used to test against errors that should never happen during development – Max Koretskyi Oct 23 '13 at 14:51
@Maximus My point (and John's too) is that even though debugging code shouldn't affect the program's state, in complex systems sometimes it inadvertently **does**. And then all hell breaks loose when you remove it for production. External tests are much more reliable. – syam Oct 23 '13 at 14:57
@Maximus: I'm not sure about "most people" but I can tell you if Code Complete recommends using asserts, then I disagree with Code Complete. My advice comes from 20 years of experience writing production systems. I'd also point out that Code Complete was written in a different era -- long before Unit Testing was popular. – John Dibling Oct 23 '13 at 15:01
@syam, I understand, thanks. However, unit tests are not a replacement of asserts, but complements them. There is a lot of proofs of that on SO, for example [this one](http://stackoverflow.com/questions/2595701/what-is-the-role-of-asserts-in-c-programs-that-have-unit-tests). – Max Koretskyi Oct 23 '13 at 15:01
You're of course free to hold whatever opinions you wish. I would say that your assertion (pun) that "unit tests are not a replacement of asserts, but complements them" is exactly that -- an opinion. One that I disagree with. – John Dibling Oct 23 '13 at 15:05
@JohnDibling, thanks for you answer. I don't have my opinion yet, as I don't have enough experience with assertions. It's what most people on SO agree upon. Also, for example, [Java guide](http://docs.oracle.com/javase/1.4.2/docs/guide/lang/assert.html) recommends them. It could be, that after using them for a while I might come to a conclusion just like yours, but currently I'm curious whether assertions should be included into test-ready code – Max Koretskyi Oct 23 '13 at 15:08

score 0 · Answer 3 · answered Oct 23 '13 at 14:06

0

If you are developing anything from .NET like MFC or C# then ASSERTS will not be included in the Release builds, you dont have to do any modifications. Leave them be for better debugging if any bugs surface(which will ;) ). As for JS and PHP I would say logs are a better, as asserts or alerts popping up with developer messages will look REALLY bad and baffling.

P.S> All views are personal

answered Oct 23 '13 at 14:06

Aakash

1,860
19
30

Alerts popping up a server when no-one is listening are even more annoying ;-) – doctorlove Oct 23 '13 at 14:29

should asserts remain in the testing version

3 Answers3