PacketReaderTest::testFiltersRemotion()

Hi

When running the testFiltersRemotion() I get results like:

[junit] 248

[junit] ------------- ---------------- ---------------

[junit] Testcase: testFiltersRemotion(org.jivesoftware.smack.PacketReaderTest): FAILED

[junit] expected:<248> but was:<200>

[junit] junit.framework.AssertionFailedError: expected:<248> but was:<200>

The first point I note is that the call to assertEquals:

assertEquals(valCounter(), repeat * 2 * 10);

Has the arguments reversed. It should be assertEquals(expected, actual), so:

assertEquals(repeat * 2 * 10, valCounter());

Also, I think that the expected is:

  • Two PacketListeners

  • Two PacketFilters

  • repeat (10) number of (outer) loops

  • 5 number of (inner) loop

Which is: 2210*5 = 200 (I know that this is the same, but the logic of the test expression in the code would be better aligned with the code execution logic if it were expressed in this way).

Still, the test fails more often than passes. I have the run the test quite a few times now. Sometimes it passes, sometimes not. When it doesn’t, the actual number varies from, say 190 to 248.

Looking at at the server debug log I can see that 300 messages were sent.

The number of messages sent is composed of the first inner loop of 5, within which two messages are sent, which is 5210 = 100. Since each message has both the listener and the filter incrementing the count, that gives us the 200 we expect.

Plus, the test code also has another inner loop of 10 iterations, after the listeners are removed, which is 10210 = 200. So that is 300 messages that the server receives and sends out again.

I have checked the server log several times. The server log shows 300 messages consistently even when the actual result varies as described above.

There is definitely something odd going on here.

Regards

Nathan

/**

  • Tests that PacketReader adds new listeners and also removes them correctly.

*/

public void testFiltersRemotion() {

resetCounter();

int repeat = 10;

for (int j = 0; j < repeat; j++) {

PacketListener listener0 = new PacketListener() {

public void processPacket(Packet packet) {

System.out.println(“Packet Captured”);

incCounter();

}

};

PacketFilter pf0 = new PacketFilter() {

public boolean accept(Packet packet) {

System.out.println(“Packet Filtered”);

incCounter();

return true;

}

};

PacketListener listener1 = new PacketListener() {

public void processPacket(Packet packet) {

System.out.println(“Packet Captured”);

incCounter();

}

};

PacketFilter pf1 = new PacketFilter() {

public boolean accept(Packet packet) {

System.out.println(“Packet Filtered”);

incCounter();

return true;

}

};

getConnection(0).addPacketListener(listener0, pf0);

getConnection(1).addPacketListener(listener1, pf1);

// Check that the listener was added

Message msg0 = new Message(getConnection(0).getUser(), Message.Type.normal);

Message msg1 = new Message(getConnection(1).getUser(), Message.Type.normal);

for (int i = 0; i < 5; i++) {

getConnection(1).sendPacket(msg0);

getConnection(0).sendPacket(msg1);

}

try {

Thread.sleep(100);

}

catch (InterruptedException e) {

e.printStackTrace();

}

// Remove the listener

getConnection(0).removePacketListener(listener0);

getConnection(1).removePacketListener(listener1);

try {

Thread.sleep(300);

}

catch (InterruptedException e) {

e.printStackTrace();

}

for (int i = 0; i < 10; i++) {

getConnection(0).sendPacket(msg1);

getConnection(1).sendPacket(msg0);

}

try {

Thread.sleep(100);

}

catch (InterruptedException e) {

e.printStackTrace();

}

}

System.out.println(valCounter());

assertEquals(valCounter(), repeat * 2 * 10);

}

Interesting, as I am not familiar with the test case since I have never seen it fail.

If I was a gambling man, my money would be on the Thread.sleep(). I despise the usage of them in test cases as by there very nature it makes the tests inconsistent.

Automated test’s should not be inconsistent. I think this is simply a flawed test case as it is timing dependent. I also don’t see the purpose of the test itself, why is it running a loop and sending multiple messages when 1 will suffice to test the removal of the listener.

Hi

I tried altering the repeat to be just one, and the test ran correctly several times in a row, which is an improvement.

I tried staying with repeat=10 and changing sleep(100) to be 300, 500 and 1000. The test did not run properly.

In any case, for the purposes of testing the removal, you are quite right that only one message is needed, so why the test is the way it is is not clear.

BUT, something odd is happening here, and it is not obvious that altering the sleep period changes that, so this test may well have exposed a bug, and should be investiigated further. I would like to do that after I have managed to identify all of the other test issues that there are, so please create an issue that I can use for tracking purposes.

Many thanks

Nathan