New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VS2017 + C++17 = What's the Catch? = Is it me or is it you who can not make it work? #1036

Closed
DBJDBJ opened this Issue Oct 6, 2017 · 11 comments

Comments

Projects
None yet
4 participants
@DBJDBJ

DBJDBJ commented Oct 6, 2017

Title says enough ... my program.cpp contains only your tutorial snippet ..
but alas there is no output only one green line and one more bellow it:
"All tests passed (16 assertions in 1 test case)"
and that is it ?
My VS 2017 project is set to /std:c++17

Please advise ...

@DBJDBJ

This comment has been minimized.

DBJDBJ commented Oct 6, 2017

OK

-s, --success

I am in that ominous silent part of the users community for whom this is not logical ...

@martinmoene

This comment has been minimized.

Collaborator

martinmoene commented Oct 6, 2017

On success its should be completely silent, so that it's immediately clear nothing is wrong, to offer another view ;)

@DBJDBJ

This comment has been minimized.

DBJDBJ commented Oct 6, 2017

Ah debate starts :)

I beg to differ, I want a lot of nicely formated and coloured output this is why I am using testing framework to tell me all is dandy and what is it doing at the given moment. Production code uses no testing framework and THAT is completely silent. I want to see my BDD text on screen or in the log file .. not in the source code ... Also me as an CTO I want them to show me their log files form Testing stage. I do not have time to swim through the sea of tests ... I just want the results ... visible. What is being tested. Not how. That sort of thing ...

@horenmar horenmar added the Query label Oct 6, 2017

@philsquared

This comment has been minimized.

Collaborator

philsquared commented Oct 6, 2017

It’s a perfectly valid way to work, and so is supported via the -s switch that @martinmoene mentioned.
I do believe that the majority of users prefer the quiet-until-failure approach - so that is the default.
Perhaps it could be explained in the documentation, but I’m comfortable with the defaults.

@horenmar

This comment has been minimized.

Member

horenmar commented Oct 6, 2017

I am fairly sure you are the first person so far who wants the human-readable output option to be verbose by default (as opposed to machine-readable reporters being verbose by default, like the junit reporter).

In general, human-oriented UIs (whether graphical or not) need to take care not to overwhelm the user with useless information. Since the standard state of a unit test is passing (and if it is not, you need to rethink your test suite), individual passing tests shouldn't be reporter to the user. On the other hand, if a test fails, then it becomes important to report it. (Similarly, your car doesn't have a blinking light telling you that the engine is OK. It has a light telling you when the engine is not OK.)

@horenmar

This comment has been minimized.

Member

horenmar commented Oct 10, 2017

It is you btw.

@horenmar horenmar closed this Oct 10, 2017

@DBJDBJ

This comment has been minimized.

DBJDBJ commented Oct 11, 2017

@horenmar In general you should understand the need to avoid the phrases like "need" and use "should" more.

I am faced with silent tests which I have not written. I genuinely need to see them. I need all the info on the screen. Catch gives plenty of functionality to display the info for people not writing the tests, just reviewing them.

Ok, how can I try "CATCH 2", if there is such a thing?

@philsquared

This comment has been minimized.

Collaborator

philsquared commented Oct 11, 2017

@DBJDBJ I'm sorry that Catch's defaults are not exactly what you would want. As I said before, the vast majority of users prefer it the other way around - so we're not going to change that. But it's a simple matter of just passing -s on the command line.
If you prefer you could do it in code, too (see https://github.com/philsquared/Catch/blob/master/docs/own-main.md).

As for Catch2, it's currently on a branch:
https://github.com/philsquared/Catch/tree/catch2

Or grab the single header file from here (current at time of writing):
https://github.com/philsquared/Catch/releases/download/v2.0.0-develop.4/catch.hpp

@DBJDBJ

This comment has been minimized.

DBJDBJ commented Oct 11, 2017

Many thanks Phil :)

Glad to see Catch implemented in modern C++ ...

All the best

@DBJDBJ

This comment has been minimized.

DBJDBJ commented Nov 9, 2017

@philsquared

This comment has been minimized.

Collaborator

philsquared commented Nov 9, 2017

Catch2 has far less platform/ compiler dependent code than Catch 1.x had (because of the ability to target C++11 now) - but some is still necessary - mostly for #pragmas and such.

I have to admit this is the first time I've heard of someone wanting a partially pre-processed file for specific compilers. While I can see the appeal I'm not sure this is something we would prioritise supporting. Most useful open-source libraries and frameworks have such platform dependent code in - it's a "cost of doing business" in the C++ world (although that is gradually changing for the better).

I'm also not sure how much risk you see in such code in a test framework - which would not normally form part of your end product?

Thanks for bringing it up, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment