This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients Todd.Rovito, ezio.melotti, francismb, ncoghlan, ned.deily, r.david.murray, roger.serwy, terry.reedy, tshepang
Date 2013-03-23.01:43:15
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1364002996.79.0.810693265929.issue15392@psf.upfronthosting.co.za>
In-reply-to
Content
I'll start with a bit of philosophical guidance :)

1. As much as possible, push logic testing down into the non-GUI tests. Where unittest.mock can help here is when you have a piece of code to test that is *almost* independent of the GUI, but needs to call an API to either get input from the user or to send something to the screen. unittest.mock can then be set up to intercept that call, either to check that it happened as expected (display operations) or to provide a predetermined answer (input operations).

2. For the GUI tests, unittest.mock is likely to be most useful in providing predetermined input. There's only so much you can do with this, it's ultimately about ensuring that the code tested against mocked out APIs in the lower level tests at least doesn't throw exceptions when tested against the real APIs. Proper GUI testing is actually a much harder test automation problem, so it probably makes sense to focus on the non-GUI tests for now.
History
Date User Action Args
2013-03-23 01:43:16ncoghlansetrecipients: + ncoghlan, terry.reedy, ned.deily, ezio.melotti, roger.serwy, r.david.murray, Todd.Rovito, tshepang, francismb
2013-03-23 01:43:16ncoghlansetmessageid: <1364002996.79.0.810693265929.issue15392@psf.upfronthosting.co.za>
2013-03-23 01:43:16ncoghlanlinkissue15392 messages
2013-03-23 01:43:15ncoghlancreate