-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Comments
Is this of any use? |
Why does it need to be stable across machines? 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. |
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. |
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. |
@emil-e, if you're still watching - did you get anywhere with this? |
I haven't looked into it more, I'm afraid. |
Ok, no problem - thanks for taking the time to respond. |
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 (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.) |
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.The text was updated successfully, but these errors were encountered: