On May 19, 2014, 10:01 a.m., Michal Minar wrote:
> src/account/test/TestIndicationEventStream.py, line 133
>
<
http://reviewboard-openlmi.rhcloud.com/r/1741/diff/1/?file=9886#file9886l...
>
> 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.
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*
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__().
- Michal
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard-openlmi.rhcloud.com/r/1741/#review2641
-----------------------------------------------------------
On May 14, 2014, 4:31 p.m., Alois Mahdal wrote:
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard-openlmi.rhcloud.com/r/1741/
-----------------------------------------------------------
(Updated May 14, 2014, 4:31 p.m.)
Review request for OpenLMI Developers.
Repository: openlmi-providers
Description
-------
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.
Diffs
-----
src/account/test/TestIndicationEventStream.py PRE-CREATION
Diff:
http://reviewboard-openlmi.rhcloud.com/r/1741/diff/
Testing
-------
Thanks,
Alois Mahdal