On 4/27/2017 3:44 PM, Brett Cannon wrote:
On Wed, 26 Apr 2017 at 22:36 Terry Reedy <tjreedy@udel.edu <mailto:tjreedy@udel.edu>> wrote:
On 4/26/2017 1:45 PM, Brett Cannon wrote:
> E.g. I don't expect > test_importlib to be directly responsible for exercising all code in > importlib, just that Python's entire test suite exercise importlib as > much as possible as a whole. The advantage for importlib in this respect is that import statements cannot be mocked; only the objects imported, after importlib is finished.Oh, you can mock import statements. :)
Other than by pre-loading a mock module into sys.modules? If so, please give a hint, as this could be useful to me.
At the moment, I am the only one pushing idlelib patches, except when it gets included in one of Serhiy's multi-module refactoring patches (and he always nosies me).
It turns out that Louie Lu's new tool revealed a couple of other patches, though just to tests that started failing.
I had not thought about the issue that way. I should add a test_module for each remaining module, import the module, and at least create an instance of every tkinter widget defined therein, and see what other classes could be easily instantiated and what functions easily run.That seems like a good starting point. Kind of like test_sundry but with class instantiation on top of it.
I looked and saw that bdb is in 'untested'. I also discovered https://bugs.python.org/issue19417 to change that, with a 3+ year-old-patch. I plan to review it.
> I view 100% coverage as aspirational, not attainable. But if we want an > attainable goal, what should we aim for? We're at 83.44% now On what system?
Travis, where the Codecov run is driven from.
I meant OS, because
I suspect that Tkinter, ttk, turtle, and IDLE GUI-dependent tests make at least a 2% difference on GUI Windows versus no-GUI *nix.
-- Terry Jan Reedy