The general idea is to write tests that use your code in realistic ways and check the results. So if you have a function that takes an input and returns a result, you write a test that passes that function an input checks the result. If some inputs should make it error, you write a test that checks that it errors.
In web programming, a common thing is to make a web request with different variations of GET / PUT params, then check that it returns the right status code, or that the result is valid JSON, etc. Basically, try to simulate all the things a real world user would be able to use, and test that your code does what you intend for it to do. TDD is a good principle but usually seems a little too pedantic for real world programming. Where tests (in my experience) get really useful is in making sure that a new change hasn't unexpectedly broken something already written. On Thu, Jan 3, 2013 at 2:31 PM, Tino Dai <obe...@gmail.com> wrote: > > > I think what I need is a conceptual shift: how do python programmers use >> unittests? >> >> > Here at the Library, we use unit test to test the cases that have many > known inputs. For example, some of the data could come in "foo bar baz", > and some others could come in as "foo, bar, baz", and others could come in > "foo; bar; baz". As we code for each one of these cases, we write tests to > make sure that changes that we make don't break any of our former code. I > think that TDD is a good thing to strive for, but in most cases is an ideal > that can't be reached in most cases. > > Hope that helps, > Tino > > > _______________________________________________ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > http://mail.python.org/mailman/listinfo/tutor > >
_______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
