Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.python Subject: Re: Unittests and serial workflows Date: Fri, 30 Oct 2015 09:23:31 -0700 Organization: A noiseless patient Spider Lines: 17 Message-ID: <877fm4tjek.fsf@jester.gateway.sonic.net> References: <87twpcvnph.fsf@jester.gateway.sonic.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="1a9f5856d25720e42c135b990c70bebb"; logging-data="11551"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/FZxp/L6wOLAEL9ud7QwTN" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:ZYp6EIgq/NO1KNCBD55OGXkYRg0= sha1:ZNsOMElWTA9DGcWP0U2dt1le/gE= Xref: csiph.com comp.lang.python:98004 Fabien writes: >> Write B so that it doesn't require input to actually come from A, but >> rather, write or generate some other sample input. Then test B >> separately from A. > Thanks for your thoughts. I am not sure that this is always possible > in my case, but I see what you mean. It's generally difficult to take an existing program and add tests to it, if that's what you're trying to do. If you want a program with a suite of tests, it's best to write the tests at the same time that you write the code (so-called test-driven development or TDD). Writing the tests then steers the organization of the code, so that the functions are independently testable. You should also know about "mock objects" which can supply interfaces that would normally expect to do (e.g.) database queries or operations on a network. I've generally written those by hand, but I think there's a Python library module for them now.