Folks, I was thinking how our test harness can be improved to allow for
simpler, more reliable tests (captured as MESOS-8922).
One thing, MESOS-8923, comes from an observation that sometimes an
expectation in a test is satisfied by a similar but actually irrelevant
message / call. Let me give some context here.
Logically, I see two scenarios.
1. A test does not care about messages / calls of the same type but with
different fields, nor about their ordering. All it cares about is that a
specific message is eventually observed, e.g.,
EXPECT_CALL(
*scheduler,
update(_, AllOf(
TaskStatusUpdateTaskIdEq(taskInfo1),
TaskStatusUpdateStateEq(v1::TASK_STARTING))));
2. A test cares about messages of the same type, their ordering, possibly
unexpected messages, and so on. This is achieved by intercepting _all_
message and _then_ checking expectations, e.g.
EXPECT_CALL(sched, statusUpdate(&driver, _))
.WillOnce(FutureArg<1>(&taskStarting))
.WillOnce(FutureArg<1>(&taskRunning))
.WillOnce(FutureArg<1>(&taskFinished));
Note: Difference between these scenarios is vague. Ideally, 2. is expressed
in terms of 1., but this can be too verbose [1] or not supported [2].
While we can express filtering, order, etc when using gtest macros like
EXPECT_CALL, we are much limited with our own macros, like FUTURE_PROTOBUF,
DROP_PROTOBUF, FUTURE_MESSAGE and alike.
I have a POC [3] to address a part of this problem with an application
example [4]. Another application besides [2] will be some
StorageLocalResourceProviderTests that have to intercept a non-interesting
message:
Future<UpdateSlaveMessage> updateSlave2 =
FUTURE_PROTOBUF(UpdateSlaveMessage(), _, _);
Future<UpdateSlaveMessage> updateSlave1 =
FUTURE_PROTOBUF(UpdateSlaveMessage(), _, _);
AWAIT_READY(updateSlave1);
AWAIT_READY(updateSlave2);
ASSERT_TRUE(updateSlave2->has_resource_providers());
ASSERT_EQ(1, updateSlave2->resource_providers().providers_size());
The POC can be extended to other FUTURE_* and DROP_* macros.
Do folks think it is a useful addition? Are there more cases where we can
benefit from filtering messages / protobufs?
[1]
https://github.com/apache/mesos/blob/c020a130afd55dd3f5702a23b13f8234e0ace391/src/tests/default_executor_tests.cpp#L288-L320
[2]
https://github.com/apache/mesos/blob/c020a130afd55dd3f5702a23b13f8234e0ace391/src/tests/master_slave_reconciliation_tests.cpp#L417-L428
[3] https://github.com/rukletsov/mesos/commits/alexr/matched-protobuf
[4]
https://github.com/rukletsov/mesos/commit/9883222ba9b6eaaeb04ed4d606aaf5013d858c7b
Alex
