Re: [openstack-dev] [Fuel] fake threads in tests

[Przemyslaw Kaminski]

Yes, I agree, basically the logic of introducing promises (or fake
threads or whatever they are called) should be tested itself too.

Basically what this is all about is mocking Astute and be able to
easily program it's responses in tests.

P.


On 02/18/2015 09:27 AM, Evgeniy L wrote:
> Hi Przemyslaw,
> 
> Thanks for bringing up the topic. A long time ago we had similar
> topic, I agree that the way it works now is not good at all,
> because it leads to a lot of problems, I remember the time when our
> tests were randomly broken because of deadlocks and race conditions
> with fake thread.
> 
> We should write some helpers for receiver module, to explicitly and
> easily change state of the system, as you mentioned it should be
> done in synchronous fashion.
> 
> But of course we cannot just remove fake and we should continue
> supporting it, some fake thread specific tests should be added to
> make sure that it's not broken.
> 
> Thanks,
> 
> On Mon, Feb 16, 2015 at 2:54 PM, Przemyslaw Kaminski 
> mailto:pkamin...@mirantis.com>> 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.
> 
> P.
> 
> [1] https://bugs.launchpad.net/fuel/+bug/1421599
> 
> __
>
> 
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
> 
> 
> 
> 
> __
>
> 
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
> 

__
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

Re: [openstack-dev] [Fuel] fake threads in tests

[Evgeniy L]

Hi Przemyslaw,

Thanks for bringing up the topic. A long time ago we had similar topic,
I agree that the way it works now is not good at all, because it leads to
a lot of problems, I remember the time when our tests were randomly
broken because of deadlocks and race conditions with fake thread.

We should write some helpers for receiver module, to explicitly and easily
change state of the system, as you mentioned it should be done in
synchronous fashion.

But of course we cannot just remove fake and we should continue supporting
it, some fake thread specific tests should be added to make sure that it's
not
broken.

Thanks,

On Mon, Feb 16, 2015 at 2:54 PM, 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.
>
> P.
>
> [1] https://bugs.launchpad.net/fuel/+bug/1421599
>
> __
> 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
>
__
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

Re: [openstack-dev] [Fuel] fake threads in tests

[Jay Pipes]

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

Re: [openstack-dev] [Fuel] fake threads in tests

[Przemyslaw Kaminski]

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.

P.

> 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

__
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

Re: [openstack-dev] [Fuel] fake threads in tests

[Jay Pipes]

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?


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