Skip to content
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

Some way to get the current test case/section path #522

Open
emil-e opened this issue Oct 22, 2015 · 8 comments
Open

Some way to get the current test case/section path #522

emil-e opened this issue Oct 22, 2015 · 8 comments
Labels

Comments

@emil-e
Copy link

emil-e commented Oct 22, 2015

I'm doing some for integrating RapidCheck with Catch but I need some way to retrieve a stable (across different builds) but unique identifier for the current section. I.e., I would like to get something "MyTestCase/MySection/MySubsection". I was thinking of making a reporter but I would need to replace any reporter that a user specified.

Any ideas? It doesn't have to be a string, just something stable across builds on different machines. For that reason, I cannot use __FILE__ because it depends on your build.

@elken
Copy link

elken commented Nov 4, 2015

Is this of any use?

@philsquared
Copy link
Collaborator

Why does it need to be stable across machines?
Internally sections are identified by a string that is built up using (amongst other things) the file and line number - but that doesn't meet your criteria.

I also suspect you'll run into problems with the re-run mechanism sections uses (was it you I was talking to about this elsewhere?).

I've just (yesterday) pushed a big commit that completely reworks the section tracking logic in a way that allows different things to be hooked in. This is going to be the basis of my own property based testing feature (a reworking of the never-quite-finished generators feature). However it may be useful for you if you still want to integrate RapidCheck.

I think with this new mechanism you should be able to construct a unique ID based on the ambient test case name and stack of section names - which you'll have access to. I haven't documented any of this yet - and am reluctant to do so just yet as it's all brand new and still subject to change - but we can talk more if you're interested.

@emil-e
Copy link
Author

emil-e commented Nov 4, 2015

The use case for this is that when RapidCheck finds a failing test cases (including minimal counter examples), it will print a blob which you can then pass to RapidCheck to reproduce the exact same failures again. This will be a serialized map from property identifier to the parameters required to reproduce the failure for that property (i.e. seed, size, path to walk through the shrink tree). This is especially useful if you run RapidCheck on a build server and trigger an improbably bug that you then want to debug. In that case, you just copy the blob and pass it to RapidCheck when it runs locally. This requires that the properties have the same identifiers on both machines.

I don't recall anything about re-runs... how will that cause issues?

Using the stack of names you are describing would be ideal so I am definitely interested.

@philsquared
Copy link
Collaborator

The way sections work is that the whole test case is run multiple times - each time following a different path through to a different leaf section. The section tracking logic I talked about is what does the bookkeeping for that. My own attempt at a basis for property based testing (a form of parameterised testing) - generators - has had a long standing issue where they are basically just not compatible with sections for that reason. This new rewrite is in preparation for fixing that - and I've done it in a modular way that should, in theory, be open for anything else to hook into (with a little integration code).

I'll need to take another look at how much of the section naming is available to you within that - I may need to expose a bit more - but if you take a look at the IndexTracker class in the latest develop build you should get an idea.

@philsquared
Copy link
Collaborator

@emil-e, if you're still watching - did you get anywhere with this?

@emil-e
Copy link
Author

emil-e commented Feb 14, 2017

I haven't looked into it more, I'm afraid.

@philsquared
Copy link
Collaborator

Ok, no problem - thanks for taking the time to respond.
Do you think it's something you'll get back to - or should we close this ticket?

@mlimber
Copy link
Contributor

mlimber commented Apr 28, 2017

I landed here when trying to find the current section name for a different reason. In my case, I am using the Trompeloeil mocking framework and have a test like:

TEST_CASE("Test Foo","")
{
    // ... Create mock
    REQUIRE_CALL( mock, Foo() ); // A macro supplied by trompeloeil
    SECTION("x") { /*...*/ }
    SECTION("y") { /*...*/ }
 }

Note that the REQUIRE_CALL() is an expectation common to both sections, and when it fails, it is triggered at the end of scope, which is outside each of the sections. I would like to know which section ("x" or "y") is currently running so I could add a line in each section like INFO( Catch::GetCurrentSectionName() ) instead of duplicating the section name or having a different string there explicitly. Is there a way to get that? My current alternative is to add INFO( __FILE__ ": " << __LINE__ ).

(This is really a workaround. The ideal for me as a user would be to have Catch print the last successfully completed nested section on failure. Then I wouldn't need an info statement at all.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants