That would just race the other way around.

However, I missed the fact that the check of client's contents had no chance to catch an issue, as the main thread were not entering asyncore.loop after allowing the server to send.

Updated patch (against 3.3) follows (dunno why, file were not attachable).

diff -r 035aa81c2ba8 Lib/test/test_asynchat.py
--- a/Lib/test/test_asynchat.py Tue Jun 02 18:53:46 2015 -0400
+++ b/Lib/test/test_asynchat.py Mon Jun 08 20:14:27 2015 +0200
@@ -30,6 +30,7 @@
             # This will be set if the client wants us to wait before echoing data
             # back.
             self.start_resend_event = None
+            self.received_len = 0
 
         def run(self):
             self.sock.listen(1)
@@ -41,6 +42,7 @@
                 data = conn.recv(1)
                 if not data:
                     break
+                self.received_len += len(data)
                 self.buffer = self.buffer + data
 
             # remove the SERVER_QUIT message
@@ -226,13 +228,14 @@
         # where the server echoes all of its data before we can check that it
         # got any down below.
         s.start_resend_event.set()
+        asyncore.loop(use_poll=self.usepoll, count=300, timeout=.01)
         s.join()
 
-        self.assertEqual(c.contents, [])
+        self.assertEqual(len(c.contents), 0)
         # the server might have been able to send a byte or two back, but this
         # at least checks that it received something and didn't just fail
         # (which could still result in the client not having received anything)
-        self.assertGreater(len(s.buffer), 0)
+        self.assertGreater(s.received_len, 0)
 
 
 class TestAsynchat_WithPoll(TestAsynchat):