On May 19th, 2014, 10:01 a.m. UTC, Michal Minar wrote:

src/account/test/TestIndicationEventStream.py (Diff revision 1)
		37	'conn': self.conn,
		38	'delay_action': 0.1,
		39	'delay_chillout': 3,
		40	'listener_host': "localhost",
		41	'listener_port': 11001,

Most of these seem like common options to many other tests. I'd try to move them somewhere higher in hierarchy to lmi.test package. It would make sense to let them be overridden by environment variables.

Also name *options* is not much descriptive - especially since they are not used anywhere in this module (except of being modified in few tests).

I have fixed this by having IndicationStreamTestCase (finally as regular parent--not a mixin) load these from environment variables.  This was also extended to username_prefix as username_strength, which have been generalized and renamed to gen_prefix and gen_strength.

Since commits have been split, fixed version will appear in a new review request.

On May 19th, 2014, 10:01 a.m. UTC, Michal Minar wrote:

src/account/test/TestIndicationEventStream.py (Diff revision 1)
		133	self.options['delay_chillout'] = 20

Since the order of tests execution is not deterministic, this assignment nondeterministically affect other tests which do not modify options. Maybe this option could be passed as a keyword argument to self.assertExpectedStream that would treat them as additional options to driver.

On May 19th, 2014, 1:04 p.m. UTC, Alois Mahdal wrote:

Are you sure?  AFAIK, unittest.TestCase instance is thrown away after each test, and born again, and setUp/tearDown is called each time.  (Yes. it's confusing behavior of the unittest framework:  you define set of methods of TestCase and it looks like "normal class" but in reality they never exist together in one instance; instead, new "empty" instance with only one test* method is created per case.)

So I believe new dict self.options is assigned in setUp each time, so it does not actually influence other cases.

That said, I agree it could be more explicit; maybe by passing via the assert*

On May 19th, 2014, 1:48 p.m. UTC, Michal Minar wrote:

Ah ... sorry, I was wrong about it. unittest.TestCase instance is not thrown away after each particular test. Just the setUp() method is called before each test_*() method. I confused it with __init__().

I've decided not to make it explicit part of execute call (not assertExpectedStrem--that one does not actually work with driver at all).

I'm not sure about it since the execute() relies on self.driver_options --- then part of data would come from self and part from args, which could be confusing.  If it should be explicit, we should then pass whole dict everytime, but that beats the intent to have tester type as little as possible.

As we agreed, changing the option as of itself is not a problem.

- Alois

On May 14th, 2014, 4:31 p.m. UTC, Alois Mahdal wrote:

Basic set of tests with focus on this flow:

  1. add set of subscriptions
  2. add set of handlers
  3. trigger sequence of "interesting" events
  4. collect indications
  5. and make assertions as needed

Currently the assertions are mostly that correct classes have been
delivered, reporting the events in correct order.