On 02/16/2015 08:18 AM, Przemyslaw Kaminski wrote:
On 02/16/2015 01:55 PM, Jay Pipes wrote:
On 02/16/2015 06:54 AM, Przemyslaw Kaminski wrote:
Hello,

This somehow relates to [1]: in integration tests we have a
class called FakeThread. It is responsible for spawning threads
to simulate asynchronous tasks in fake env. In
BaseIntegrationTest class we have a method called
_wait_for_threads that waits for all fake threads to terminate.

In my understanding what these things actually do is that they
just simulate Astute's responses. I'm thinking if this could be
replaced by a better solution, I just want to start a discussion
on the topic.

My suggestion is to get rid of all this stuff and implement a
predictable solution: something along promises or coroutines
that would execute synchronously. With either promises or
coroutines we could simulate tasks responses any way we want
without the need to wait using unpredictable stuff like sleeping,
threading and such. No need for waiting or killing threads. It
would hopefully make our tests easier to debug and get rid of the
random errors that are sometimes getting into our master branch.

Hi!

For integration/functional tests, why bother faking out the threads
at all? Shouldn't the integration tests be functionally testing the
real code, not mocked or faked stuff?

Well you'd need Rabbit/Astute etc fully set up and working so this was
made for less painful testing I guess. These tests concert only
Nailgun side so I think it's OK to have Fake tasks like this. Full
integration tests with all components are made by the QA team.

OK, so these are not integration tests, then. Sounds like they are merely unit tests, and as such should just mock out any cross-function-unit boundaries and not need any FakeThread class at all.

Best,
-jay

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to