[Beaker-devel] Integration tests vs unit tests

Nick Coghlan ncoghlan at redhat.com
Fri Sep 6 05:30:42 UTC 2013


On 09/06/2013 03:15 PM, Raymond Mancy wrote:
> 
> 
> ----- Original Message -----
>> From: "Nick Coghlan" <ncoghlan at redhat.com>
>> To: "beaker-devel" <beaker-devel at lists.fedorahosted.org>
>> Sent: Friday, September 6, 2013 12:27:54 PM
>> Subject: [Beaker-devel] Integration tests vs unit tests
>>
>> Just dumping a transcript of an IRC conversation between rmancy and I
>> about unit tests vs integration tests (in the context of the patch that
>> makes the createrepo command configurable:
>> http://gerrit.beaker-project.org/#/c/2208/).
>>
>> At the moment, Beaker's unit testing is fairly minimal, so we don't have
>> a good, quick, confidence building set of tests to run before pushing to
>> Gerrit, just the full set of integration tests (which can take half an
>> hour or more to run, depending on the details of your system).
>>
>> It's going to take some time for us to improve Beaker's unit testing
>> story, this just struck me as an expedient way to get something on
>> record that this is the direction we're likely to be heading :)
>>
>> Cheers,
>> Nick.
> 
> Ok, so should we be aiming to remove the need for a database?
> Perhaps we could use an in-memory sqlite database for that.
> 
> Do we want to physically seperate our unit tests, or just 'tag' them
> and then use something like this http://nose.readthedocs.org/en/latest/plugins/attrib.html.

I'm broadly happy with the current setup (integration tests in a
dedicated tree, unit tests alongside the code they test).

If it needs a running database or webserver (including all selenium
tests) then it goes in the integration test tree, otherwise it goes in
the appropriate source tree.

There are really only two things I'd like to see changed:

- an easy way to invoke all the unit tests *without* invoking the
integration tests. This should just be a matter of tweaking the path
used in run-tests.sh to avoid including the integration test tree. A
command line arg, environment variable, or just skipping the integration
tests when the script is run from somewhere other than the
IntegrationTests directory would probably work for that. Since we
already have a check for the last one, and it doesn't run the risk of
interfering with passing arguments through to nose, I'll write a patch
based on that.

- grouping the unit tests into test subpackages and using explicit
relative imports, rather than having them live as peers to the source
files they're testing. This makes the test files easier to separate out
for various purposes, including making it possible to create test helper
modules without polluting the ordinary package namespaces.

Cheers,
Nick.

-- 
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane

Testing Solutions Team Lead
Beaker Development Lead (http://beaker-project.org/)


More information about the Beaker-devel mailing list