Unit test guide and catch example

[KipHamiltons]

Very cool and epic guides. One covers unit testing, another gives a little detail of a catch example.

TODO:

• Add stuff about catch BDD tests to catch guide, and try to bring focus onto that style

Preview

[ysims]

It might be good to link to the catch guide in the how to write tests guide? I'd even maybe go as far as to say, combine the pages (see troubleshooting page)? Otherwise I'd also suggest that 'Catch Getting Started' should be under 'Main Codebase'.
If I wanted to write tests and knew nothing, 'Catch Getting Started' wouldn't stand out to me as a page that would hold the answers I seek.

[Crafty15]

The overflow thing is still a bit hazy to me. Most reference material i've read mentions handling min - 1 and max + 1 (values across boundaries). I suppose we have cases where we don't want to do this. If so, maybe we could state our reasoning.

[JosephusPaye]

As to the question of whether or not you should test overflow/underflow/similar boundary conditions:

If the piece of code you're testing could get under/overflowed input as a part of its normal operation, then you want to test that. If it doesn't, then you don't have to test it. Put another way, if you're testing a function that has explicit knowledge of boundary or exceptional conditions (it uses a conditional, try/catch, checks that its inputs are not out of bounds, etc), you want to test on and around those boundaries and conditions.

Essentially, you want your tests to cover as many code paths as possible, to verify that everything it attempts to do, it does correctly. Most of the time the boundary conditions you'll be testing will be based on some specific numeric value in the code being tested. For example, if you're testing a function that takes an input x (or an input that influences x) and has if (x <= 100) { ... } somewhere in it, you want to test x = 99, x = 100, and x = 101, at a minimum.

[CMurtagh-LGTM]

As to the question of whether or not you should test overflow/underflow/similar boundary conditions:

If the piece of code you're testing could get under/overflowed input as a part of its normal operation, then you want to test that. If it doesn't, then you don't have to test it. Put another way, if you're testing a function that has explicit knowledge of boundary or exceptional conditions (it uses a conditional, try/catch, checks that its inputs are not out of bounds, etc), you want to test on and around those boundaries and conditions.

Essentially, you want your tests to cover as many code paths as possible, to verify that everything it attempts to do, it does correctly. Most of the time the boundary conditions you'll be testing will be based on some specific numeric value in the code being tested. For example, if you're testing a function that takes an input x (or an input that influences x) and has if (x <= 100) { ... } somewhere in it, you want to test x = 99, x = 100, and x = 101, at a minimum.

Bounds checking is completely different to integer overflow. Why are you linking my comment for integer overflow then talking about bounds checking???

Integer overflow is if you have 0111 as a 4 bit integer with two's complement, so this would represent 7. Then if we add one we get 1000, which with two's complement is -8. The c++ standard lists this as undefined behaviour

@Crafty15 @JosephusPaye

[JosephusPaye]

I was responding to the thread your comment started. It would have been more accurate to link to Liam's comment in that thread.

That said, I wasn't talking about bounds checking specifically, but the general testing of boundary conditions (of which arithmetic integer over/underflows are a subset). In your example, 7 is by definition a boundary value of a 4-bit int with two's complement.

[Bidski]

Partial review for now