On Wed, 6 May 2015, Robert Collins wrote:
Its actually an antipattern. It tells testr that tests are appearing
and disappearing depending on what test entry point a user runs each
time.
testr expects the set of tests to only change when code changes.
So, I fully expect that this pattern is
On 05/06/2015 04:57 AM, Chris Dent wrote:
On Wed, 6 May 2015, Robert Collins wrote:
Its actually an antipattern. It tells testr that tests are appearing
and disappearing depending on what test entry point a user runs each
time.
testr expects the set of tests to only change when code
On 14 February 2015 at 10:26, Joe Gordon joe.gord...@gmail.com wrote:
Digging through the logs this originated from this bug:
https://bugs.launchpad.net/tempest/+bug/1260710
Its probably not needed everywhere and in all the clients.
So I've looked more closely at this.
Its actually an
On Fri, Feb 13, 2015 at 11:57 AM, Joe Gordon joe.gord...@gmail.com wrote:
1.
A few months back we started the process to remove the tempest CLI
tests from tempest [0]. Now that we have successfully pulled novaclient
CLI
tests out of tempest, we have the process sorted
1.
A few months back we started the process to remove the tempest CLI
tests from tempest [0]. Now that we have successfully pulled
novaclient CLI
tests out of tempest, we have the process sorted out. We now
have a process
that should be easy to follow for each project,
What's the test path thing for? Testr should be able to filter out unit
tests or vice versa without altering discovery.
On 14 Feb 2015 08:57, Joe Gordon joe.gord...@gmail.com wrote:
1.
A few months back we started the process to remove the tempest CLI
tests from tempest [0].
Digging through the logs this originated from this bug:
https://bugs.launchpad.net/tempest/+bug/1260710
Its probably not needed everywhere and in all the clients.
On Fri, Feb 13, 2015 at 1:06 PM, Robert Collins robe...@robertcollins.net
wrote:
What's the test path thing for? Testr should be
