This is great

why not just implement bool inRange(T,T,T) and then assert(inRange(x, min, max)); it is more than obvious that
Chamois::Assert::That(<actual_value>).Should().NotBe(<expected_value>); is bad because it introduces new complexity and imho it isn't more readable than assert(>= <)

I don't mean to sound insulting, but that looks a lot less readable to me. I don't know if it's just me.

Maybe you could get used to it, but I don't like chained methods. A simple "<" is much more clear to me than "LessThan". It's less for me to parse, and I think in symbols instead of English when I'm doing anything vaguely mathematical.

I don't mean to sound insulting, but that looks a lot less readable to me. I don't know if it's just me.

Maybe you could get used to it, but I don't like chained methods. A simple "<" is much more clear to me than "LessThan". It's less for me to parse, and I think in symbols instead of English when I'm doing anything vaguely mathematical.

Completely agree with you. The proposed syntax in this article is FAR too verbose. If an individual really has problem reading just simple assertions, then they need more experience in the language. If the assertions are too complex to be readable, then the assertions need to be broken up into simpler statements that are asserted individually.

Code readability comes from isolating statements of computation and keeping them simple. That might be more lines of code, but it is far easier to read than just appending more and more function calls to make the code look like a sentence

I can understand the advantages of having a more verbose version if it is mainly for use with Unit testing. On the other hand, I will agree to agree with the others in that I find reading operators and binary expression easier than the more verbose approach.

Another aspect which I am not entirely convinced about either is the fact that the asserts are built from several function calls. I tend to prefer inline implementation which when hitting an assert will break into the calling code, rather than a few scopes down.

I wouldn't mind seeing it used in a concrete Unit Test sample to have a feel for it though.

Keep it coming!

I tend to use try catch throw instead of assertions in my unit tests since sometimes those tests will show in working code?

So take the above example:

assert(my_variable == true);

<=>

if(my_variable!=true) throw MyVariableIsNotTrueException();

and catch it some where possibly?

But all approaches raise the question what you trying to do in the unit test. For the author here it seems it has to do with READIBILTY.

I tend to agree it's a bit less readable cause of the namespace in front(but that could be removed with a using) and Should() tends to be vague but makes sense from a literal word. Wolud be nice tho if you could use the cast operator and then you could make should behave like a C# property in C++ :)

Digging a little deeper you could also make it more readable by aligning with a mock in a vector input output model for your unit test. Much easier to administrate imho. IE

Mock looks like this

| Input1 Input2 ...| | Input1 Input2

| .... |

| Output1 ...Output2 | <==>| foo(Input1) foo(Input2)

LHS RHS

if LHS and RHS equal test passes

Then you could use remaining unit tests to prove the rest

Once you get your heard around vectors imho it's MORe concise. The problem with english rules is it's great for short set of rules. When it spans many pages it can just take up alot of time and potentially more difficult to debug

Cheers,

Patrick :)