[TIP] A quick guide to testing (for the khmer project)

John Wong gokoproject at gmail.com
Thu Jul 24 10:18:41 PDT 2014


On Thu, Jul 24, 2014 at 7:04 AM, C. Titus Brown <ctb at msu.edu> wrote:

> Hey Terry,
> Do you have suggestions for a good, concise discussion of
> the difference between unit tests and functional tests?
>
> thanks,
> --titus
>
>
Thought I will give my first 0.01 cent as a recent grad, though most people
here have more experience than I do.

When I was an undergrad I asked here on TIP mailing list:
http://comments.gmane.org/gmane.comp.python.testing.general/5333

In the end, when I gave my talk at school, I refer to
http://googletesting.blogspot.com/2010/12/test-sizes.html

There are many types of testing techniques and I'd say screw most of the
subtle differences. I went with that table and always remember there are
only three types of tests: unit test, integration and functional.

unit test: true unit test means mocking out all dependencies while testing
a specific function or method. This includes built-in functions if
necessary (e.g. Math.random) The fewer module interaction the better.

integration test: mock out necessary module interaction and external
systems (filesystem, network, database) whenever possible or whenever I
feel it is necessary. When it comes to database model testing, I test
individual model and their methods. I can test them with or without a
database, depending on how I feel about having a database or not (some ORM
makes testing easier!!). I can test the individual model instance creation,
update and deletion of models with sqlite or with a real production
database like postgresql. The rationel is that (1) I might have PostgreSQL
datatype (like JSON) which is not supported by sqlite, or (2) I am going to
use postgres in functional test anyway. The time of setting up a fresh
database in postgres is not that bad in reality. I can waste 5 seconds for
the total 100 model tests if I have to.

function test: as the google char suggested, go full.

The rest: smoke, regression, etc I just write them as needed. I can
careless about their actual definition. When I see a bug, I fix the code,
write the assertion and done. Different organization has different opinion
on how they write test.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20140724/b217f256/attachment.htm>


More information about the testing-in-python mailing list