[test] --catch_system_errors=no doesn't work with minimal test
When using boost/test/minimal.hpp, it doesn't respond to the presence of --catch_system_errors=no, which makes it unreasonably difficult to debug problems on Windows. All I get is an exception caught by the test library, with all of the info about the real cause of the error lost, which is absolutely unhelpful. It seems to me that the minimal configuration ought to at least be useful for writing and debugging simple test cases. -- Dave Abrahams Boost Consulting www.boost-consulting.com
When using boost/test/minimal.hpp, it doesn't respond to the presence of --catch_system_errors=no, which makes it unreasonably difficult to debug problems on Windows. All I get is an exception caught by the test library, with all of the info about the real cause of the error lost, which is absolutely unhelpful. It seems to me that the minimal configuration ought to at least be useful for writing and debugging simple test cases.
Minimal testing facility doesn't process any CLA. Execution monitor by default catches all the errors (which I think reasonable default). If you prefer more customization use different component. Easiest substitution would be: boost/test/included/test_exec_monitor.hpp Gennadiy
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
When using boost/test/minimal.hpp, it doesn't respond to the presence of --catch_system_errors=no, which makes it unreasonably difficult to debug problems on Windows. All I get is an exception caught by the test library, with all of the info about the real cause of the error lost, which is absolutely unhelpful. It seems to me that the minimal configuration ought to at least be useful for writing and debugging simple test cases.
Minimal testing facility doesn't process any CLA.
http://boost.org/libs/test/doc/usage/command_line.html and http://boost.org/libs/test/doc/usage/msvc_net.html#t2 don't make that clear. BTW, "CLA" is not a universally understood abbreviation. (http://boost.org/libs/test/doc/open_issues.html)
Execution monitor by default catches all the errors (which I think reasonable default).
I'm not sure it is. It seems to me that Boost.Test has two uses: 1) for writing effective unit and regression tests 2) for writing "resilient" software Given its name, I think (1) should be emphasized, but I think the "catches all errors" behavior is more appropriate to (2).
If you prefer more customization use different component. Easiest substitution would be:
boost/test/included/test_exec_monitor.hpp
That worked; thank you. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uu0ew8rxm.fsf@boost-consulting.com...
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
When using boost/test/minimal.hpp, it doesn't respond to the presence of --catch_system_errors=no, which makes it unreasonably difficult to debug problems on Windows. All I get is an exception caught by the test library, with all of the info about the real cause of the error lost, which is absolutely unhelpful. It seems to me that the minimal configuration ought to at least be useful for writing and debugging simple test cases.
Minimal testing facility doesn't process any CLA.
http://boost.org/libs/test/doc/usage/command_line.html and http://boost.org/libs/test/doc/usage/msvc_net.html#t2 don't make that clear.
Minimal testing facility is in many sences "crippled" relative to te rest of Boost.Test components. There is a separate chapter covering it and the rest of docs doesn't have anything to do with it. If you think it worth the effort I could explicetly specify in all places: "Is not applicable ot Minimal Testing facility"
BTW, "CLA" is not a universally understood abbreviation. (http://boost.org/libs/test/doc/open_issues.html)
It's quite frequently used. But I could unabbreviate in docs.
Execution monitor by default catches all the errors (which I think reasonable default).
I'm not sure it is. It seems to me that Boost.Test has two uses:
1) for writing effective unit and regression tests 2) for writing "resilient" software
Given its name, I think (1) should be emphasized, but I think the "catches all errors" behavior is more appropriate to (2).
I guess it's a matter of personal preferense either. I nmany cases I don't need core to fix an error anonced with "fatal error" message. And if do need I could always specify extra parameter. On the other hand regression tests runners never need this. And I wouldn't want to force them to add this parameter always. IOW I think we need more compeling reason to change a default. Gennadiy
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uu0ew8rxm.fsf@boost-consulting.com...
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
When using boost/test/minimal.hpp, it doesn't respond to the presence of --catch_system_errors=no, which makes it unreasonably difficult to debug problems on Windows. All I get is an exception caught by the test library, with all of the info about the real cause of the error lost, which is absolutely unhelpful. It seems to me that the minimal configuration ought to at least be useful for writing and debugging simple test cases.
Minimal testing facility doesn't process any CLA.
http://boost.org/libs/test/doc/usage/command_line.html and http://boost.org/libs/test/doc/usage/msvc_net.html#t2 don't make that clear.
Minimal testing facility is in many sences "crippled" relative to te rest of Boost.Test components. There is a separate chapter covering it and the rest of docs doesn't have anything to do with it. If you think it worth the effort I could explicetly specify in all places: "Is not applicable ot Minimal Testing facility"
Either that, or make it very very clear at the beginning of the minimal test docs that no other library documentation is valid for the minimal facility.
Execution monitor by default catches all the errors (which I think reasonable default).
I'm not sure it is. It seems to me that Boost.Test has two uses:
1) for writing effective unit and regression tests 2) for writing "resilient" software
Given its name, I think (1) should be emphasized, but I think the "catches all errors" behavior is more appropriate to (2).
I guess it's a matter of personal preferense either. I nmany cases I don't need core to fix an error anonced with "fatal error" message. And if do need I could always specify extra parameter.
What "extra parameter?" Where? If you mean "command line **argument**," then it doesn't apply because minimal.hpp, for some reason, ignores them.
On the other hand regression tests runners never need this.
They do if they are asked to debug a problem that nobody else can reproduce. It happens occasionally.
And I wouldn't want to force them to add this parameter always. IOW I think we need more compeling reason to change a default.
Well, when people are just dipping their toes in the test library waters they are likely to start with minimal.hpp, and they are likely to be trying to do some local testing rather than writing some test that will be run by a 3rd party under some large test harness. It seems to me that all your reasons for not changing it are directed at that case, though. -- Dave Abrahams Boost Consulting www.boost-consulting.com
What "extra parameter?" Where? If you mean "command line **argument**," then it doesn't apply because minimal.hpp, for some reason, ignores them.
That's because minimal.hpp as the name suggest, provide minimal functionally.
On the other hand regression tests runners never need this.
They do if they are asked to debug a problem that nobody else can reproduce. It happens occasionally.
Namely - occasionally(if not rarely). Test they run on a regular basis
And I wouldn't want to force them to add this parameter always. IOW I think we need more compelling reason to change a default.
Well, when people are just dipping their toes in the test library waters they are likely to start with minimal.hpp,
God, I hope not. The only reason this component exists is because some people here on the list, who were familiar with original testing library wanted something for backward compatibility. In fact for the new users I don't see almost any reasons to use it at all. Boost.Test provides better alternatives. Gennadiy
At 1:57 AM -0500 11/7/05, Gennadiy Rozental wrote:
Well, when people are just dipping their toes in the test library waters they are likely to start with minimal.hpp,
God, I hope not. The only reason this component exists is because some people here on the list, who were familiar with original testing library wanted something for backward compatibility. In fact for the new users I don't see almost any reasons to use it at all. Boost.Test provides better alternatives.
Quoting from the introduction to the documentation section for the Minimal Testing facility: Minimal testing facility does not require linking with external components, so could be a component of choice for simple and quick testing needs. Perhaps something more akin to your message above should be in this introduction. Note that one of my co-workers also went down this minimal-testing rat hole, after I had extolled the capabilities of Boots.Test but before I'd written the brief "How we use Boost.Test" introduction for my co-workers (which basically says, "Use the auto unit test framework, unless you have a really good reason not to, and then think hard about that reason for a while first.").
Kim Barrett <kab@irobot.com> writes:
At 1:57 AM -0500 11/7/05, Gennadiy Rozental wrote:
Well, when people are just dipping their toes in the test library waters they are likely to start with minimal.hpp,
God, I hope not. The only reason this component exists is because some people here on the list, who were familiar with original testing library wanted something for backward compatibility. In fact for the new users I don't see almost any reasons to use it at all. Boost.Test provides better alternatives.
Quoting from the introduction to the documentation section for the Minimal Testing facility:
Minimal testing facility does not require linking with external components, so could be a component of choice for simple and quick testing needs.
Yes, that's exactly what I thought would lead people to reach for minimal.hpp as a way of getting started. Either minimal.hpp should be made to be useful for the most basic use cases, where an individual user will want to debug a problem that it finds, or you should do a much better job of discouraging people from using it. Personally, I think supporting --catch_system_errors=no in minimal.hpp is so trivial as to be not worthy of an argument, but if you really insist on making first-time users jump through hoops, minimal.hpp should be given a different name in the public docs (like backward_compatibility.hpp) -- you can just make that header #include minimal.hpp -- and you should do something to make it much less attractive, like for example, stating up front that it's no good for JIT debugging. -- Dave Abrahams Boost Consulting www.boost-consulting.com
God, I hope not. The only reason this component exists is because some people here on the list, who were familiar with original testing library wanted something for backward compatibility. In fact for the new users I don't see almost any reasons to use it at all. Boost.Test provides better alternatives.
Quoting from the introduction to the documentation section for the Minimal Testing facility:
Minimal testing facility does not require linking with external components, so could be a component of choice for simple and quick testing needs.
Perhaps something more akin to your message above should be in this introduction. Note that one of my co-workers also went down this
Ok. I will add some discouraging message. Gennadiy
participants (1)
-
David Abrahams -
Gennadiy Rozental -
Kim Barrett