Commit 4f06531c authored by JINMEI Tatuya's avatar JINMEI Tatuya

[trac931] added a test to reproduce the problem we had with addRemoteConfig.

Also added a note to the addRemoteConfig() document that when it's called
for a module the module cc session must not have been "started".
parent e3a81c18
......@@ -256,6 +256,10 @@ public:
* for those changes. This function will subscribe to the relevant module
* channel.
*
* If the module name is specified (spec_is_filename is false), the
* ModuleCCSession must have been constructed with start_immediately
* being false and the \c start() method must not have been called.
*
* \param spec_name This specifies the module to add. It is either a
* filename of the spec file to use or a name of module
* (in case it's a module name, the spec data is
......
......@@ -595,4 +595,14 @@ TEST_F(CCSessionTest, delayedStart) {
FakeSession::DoubleRead);
}
// Similar to the above, but more implicitly by calling addRemoteConfig().
// We should construct ModuleCCSession with start_immediately being false
// if we need to call addRemoteConfig().
// The correct cases are covered in remoteConfig test.
TEST_F(CCSessionTest, doubleStartWithAddRemoteConfig) {
ModuleCCSession mccs(ccspecfile("spec29.spec"), session, NULL, NULL);
session.getMessages()->add(createAnswer(0, el("{}")));
EXPECT_THROW(mccs.addRemoteConfig(ccspecfile("spec2.spec")),
FakeSession::DoubleRead);
}
}
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment