How to capture a Fail() condition in Python test

[jmarca]

I'm trying to write a test that fails, but it seems the usual way of calling assertRaises(...) isn't working for me

First, I can't see what exception is being thrown from logging.h, logging.cc.

Second, even wrapping the entire crashing call in a try block still doesn't catch the error.

In the source in

or-tools/ortools/constraint_solver/routing.cc

Lines 6835 to 6844 in 1931017

	void RoutingDimension::SetBreakIntervalsOfVehicle(
	std::vector<IntervalVar*> breaks, int vehicle,
	std::vector<int64> node_visit_transits) {
	if (breaks.empty()) return;
	const int visit_evaluator = model()->RegisterTransitCallback(
	[node_visit_transits = std::move(node_visit_transits)](int64 from, int64 to) {
	return node_visit_transits[from];
	});
	SetBreakIntervalsOfVehicle(std::move(breaks), vehicle, visit_evaluator, -1);
	}

, I added

  CHECK_EQ(node_visit_transits.size(), model_->Size());

What I want to do is check that this fails when called from Python, so I tried various iterations of this:

        try:
            dim.SetBreakIntervalsOfVehicle(break_intervals[0], 0, [1])
            self.fail("shouldn't happen")
        except:
            pass

Rather than catching the error, the code invoked by CHECK_EQ seems to be able to completely kill off the python caller.

test_set_break_intervals (__main__.TestRoutingModel) ... WARNING: Logging before InitGoogleLogging() is written to STDERR
F0320 23:28:15.916748 28053 routing.cc:6839] Check failed: node_visit_transits.size() == model_->Size() (1 vs. 7) 
*** Check failure stack trace: ***
Aborted

How should one go about testing that bad input causes the solver to fail?

[lperron]

You can in c++ with Google test. Le lun. 15 mars 2021 à 23:59, James Marca ***@***.***> a écrit :

…

I'm trying to write a test that fails, but it seems the usual way of calling assertRaises(...) isn't working for me First, I can't see what exception is being thrown from logging.h, logging.cc. Second, even wrapping the entire crashing call in a try block still doesn't catch the error. In the source in https://github.com/google/or-tools/blob/193101786ecb527fb76a957ce5f2efe4016836c5/ortools/constraint_solver/routing.cc#L6835-L6844, I added CHECK_EQ(node_visit_transits.size(), model_->Size()); What I want to do is check that this fails when called from Python, so I tried various iterations of this: try: dim.SetBreakIntervalsOfVehicle(break_intervals[0], 0, [1]) self.fail("shouldn't happen") except: pass Rather than catching the error, the code invoked by CHECK_EQ seems to be able to completely kill off the python caller. test_set_break_intervals (__main__.TestRoutingModel) ... WARNING: Logging before InitGoogleLogging() is written to STDERR F0320 23:28:15.916748 28053 routing.cc:6839] Check failed: node_visit_transits.size() == model_->Size() (1 vs. 7) *** Check failure stack trace: *** Aborted How should one go about testing that bad input causes the solver to fail? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2438>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUPL3IZHRL3ZMMH2EXRTJTTD2GNDANCNFSM4ZHNCDDQ> .

[jmarca]

Hmm. I don't see any of this sort of testing going on in the source.

I want to submit a small patch that prevents calling SetBreakIntervalsOfVehicle with an incorrectly sized array. Is there a good example of a test I should mimic to test this. The happy path is easy...it doesn't fail. The fail path is harder, as it crashes really aggressively.

Perhaps using the CHECK_EQ macro is a bad idea, but I don't see a better way to validate arguments in the source.

Any help appreciated so I can submit a patch that won't get rejected out of hand.

[Mizux]

Since Google do not support (i.e. disable) exceptions in C++, crashing aggressively on bad input is a feature by design I.e. you have to check your data first.
The idea at Google as any web service company is to crash early and respawn a new process (pets vs cattles...).