Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Snapper.Json.Xunit does not work in Release builds
See original GitHub issue(This is based on Snapper v1.3.1)
Since the XUnit integration uses StackTraces to find information about the test that is actually using it (see XUnitHelper.GetCallingTestInfo()), this cannot be used in “release” builds (i.e. any release that does not include debug symbols and/or uses extensive optimization).
As the “Remarks” section on the StackTrace documentation states:
StackTraceinformation will be most informative with Debug build configurations. By default, Debug builds include debug symbols, while Release builds do not. The debug symbols contain most of the file, method name, line number, and column information used in constructingStackFrameandStackTraceobjects.
StackTracemight not report as many method calls as expected, due to code transformations that occur during optimization.
Running tests in a release configuration might not be the default use case, but I think it’s not very unusual either. Especially in CI servers, where you want to test what you deploy, building and testing the release configuration seems valid to me. (This is, in fact, how this issue bit me.)
It would be great if future versions of Snapper could use more robust ways to automatically gather the information that XUnitSnapper so conveniently provides.
A possible alternative might be the “caller information” attributes where the compiler fills in certain information about the source file containing the call site, in particular [CallerMemberName] and [CallerFilePath].
If release configuration cannot be supported (e.g. too much effort, or technically not feasible in general), it would be great if you could at least specify this as a known limitation in a prominent place (e.g. the README file).
Thanks for the work you put into this library already! It makes snapshot test really quite convenient 😃
Issue Analytics
- State:
- Created 5 years ago
- Comments:6 (4 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Decided to not do anything for now. Snapper throws a better error which lets the user know why it’s failing.
Its also mentioned in the FAQS on how they can solve the issue. https://theramis.github.io/Snapper/FAQS.html
A solution could be to include a
propsfile to the package, with will set theOptimizeflag tofalse