17:00:29 #startmeeting Testing Working Group 17:00:29 Meeting started Thu Nov 30 17:00:29 2017 UTC. The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:29 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:29 The meeting name has been set to 'testing_working_group' 17:00:39 #chair mattclay abadger1999 bcoca 17:00:39 Current chairs: abadger1999 bcoca gundalow mattclay 17:00:44 hi 17:01:01 #info Agenda https://github.com/ansible/community/labels/testing 17:01:04 #chair ryansb 17:01:04 Current chairs: abadger1999 bcoca gundalow mattclay ryansb 17:01:07 harro 17:01:16 óla 17:01:23 bonjour 17:02:10 #topic Clarification & next steps for unit tests 17:02:48 #agreed new unit tests should be written to use pytest 17:02:56 (as agreed last meeting) 17:03:24 #info high-value porting to pytest 1) it's useful to be able to override things from the CLI. Looks like for the option flags, that is by design.. 17:03:27 https://github.com/ansible/ansible/blame/e45c763b646e0609fb9c8d8b8cdf9c200985c313/lib/ansible/playbook/play_context.py#L262 17:03:30 bah 17:03:31 #undo 17:03:31 Removing item from minutes: 17:03:44 #info high-value porting to pytest: (1) grep -ri nose test/units 17:03:56 #info high-value porting to pytest: (1) grep -r procenv test/units 17:04:06 #info (1) lets us drop the nose dependency 17:04:21 #info lets us get rid of some of our code that pytest has good builtin support for 17:05:03 I think that addresses bcoca's questions 17:05:15 abadger1999: is there something around mocks that still needs addressing? 17:05:27 gundalow: afaik, nope. 17:05:32 .hello2 17:05:32 mock continues to be useful. 17:05:33 maxamillion: maxamillion 'Adam Miller' 17:05:49 Most tests that are ported to pytest can use the mocker fixture instead of importing mock directly, though. 17:05:59 Are there different 1) Mock libraries 2) ways to mock 17:06:15 ah, that's what I was thinking 17:06:23 #chair sdoran maxamillion 17:06:23 Current chairs: abadger1999 bcoca gundalow mattclay maxamillion ryansb sdoran 17:06:32 Everyone has standardized on michael foords mock library (named mock) which is also part of the stdlib in python3. 17:06:55 Which is good as we know where he is :) 17:07:03 for (2) I use mocker to access it but it's just a light wrapper around the mock library. 17:07:55 * resmo waves 17:07:57 Oh... and moved away from using mock.patch() as a context manager as, under pytest and mocker, the patch will unwind itself once it goes out of scope. 17:08:42 (That's style though) 17:08:52 Here's an example: https://github.com/ansible/ansible/pull/33387/files#diff-7d19c1624d0977d32233184491b27e1bL118 <==== old way 17:08:55 I see mock.path() in https://github.com/ansible/ansible/pull/33387/files 17:09:22 New way ==> https://github.com/ansible/ansible/pull/33387/files#diff-7d19c1624d0977d32233184491b27e1bR145 17:09:44 gundalow: Line number? 17:10:48 hum, I'm probs not reading it correctly 17:11:02 #info https://github.com/ansible/ansible/pull/33387/files#diff-7d19c1624d0977d32233184491b27e1bL118 (oldway) 17:11:08 #chair Pilou 17:11:08 Current chairs: Pilou abadger1999 bcoca gundalow mattclay maxamillion ryansb sdoran 17:11:18 Pilou: might need to do that again 17:11:26 #info https://github.com/ansible/ansible/pull/33387/files#diff-7d19c1624d0977d32233184491b27e1bL118 (old way) 17:11:32 #info https://github.com/ansible/ansible/pull/33387/files#diff-7d19c1624d0977d32233184491b27e1bR145 (new way) 17:11:42 abadger1999: oh, I just saw mocker.patch in the new code 17:11:58 Cool. yep, that's the new way. 17:12:41 But like I say, that particular bit is style... deeply nesting via context managers feels harder to read but does the same thing. 17:13:27 Do we have something that's the bets Ansible unit test ever that we can reference in the docs 17:13:46 ie base your code on this and you will be 90% good 17:14:16 I don't know about that... I've ported a few tests from unittest over to pytest in the past few weeks (I think three PRS-worth) 17:14:31 Those can be used as examples but I'm not sure they're the best way to do it. 17:15:00 * gundalow looks at commits to see who write tests 17:15:05 *unit tests 17:15:28 I'm happy to walk through any of those PRs with someone who wants to turn them into documentation. 17:15:45 So once those PRs are reviewed and merged we can reference them on http://docs.ansible.com/ansible/devel/dev_guide/testing_units.html 17:16:24 Yep 17:16:29 First two have been merged. 17:16:38 oh, and examples on that page need updating: import unittest: 17:17:05 #action gundalow work with abadger1999 to reference good tests from dev_guide/testing_units.html 17:17:13 #action gundalow work with abadger1999 to remove unittest references from dev_guide/testing_units.html 17:17:27 #action gundalow work with abadger1999 to add links to mock & pytest to dev_guide/testing_units.html 17:17:39 Cool. 17:17:49 Anything else on that bit? 17:17:59 Pilou: Anything else from you on this? 17:18:20 nope, i didn't have time to switch an existing test 17:19:08 The nose high-value porting should be easy for a beginner to work on. 17:19:32 Pilou: That's cool. Thanks for everything you've already been doing :) 17:19:40 The removal of procenv a little harder. Once gundalow and I document some of hte pytest information that will be easier. 17:20:22 (that's all from me) 17:20:31 cool 17:20:38 #topic Unit test imports 17:20:47 So, following on from teh above 17:21:11 #info https://github.com/ansible/ansible/issues/33302 Unit tests failed without ncclient installed 17:22:28 Think that just needs: 17:22:32 except ImportError: 17:22:42 raise SkipTest("F5 Ansible modules require blah") 17:22:46 which needs documenting 17:23:02 there is ncclient in test/runner/requirements/units.txt 17:24:05 gundalow: But change SkipTest (from nose) to pytest.skip ( https://docs.pytest.org/en/latest/skipping.html ) 17:24:50 ah, thanks 17:25:21 #action gundalow to document how to skiptest pytest.skip ( https://docs.pytest.org/en/latest/skipping.html ) (though should be added to test/runner/requirements/units.txt) 17:26:23 Pilou: oh, that's a good point. Wonder if they are not installing from that before running tests, I'll aslk 17:26:26 Although we have `test/runner/requirements/units.txt`, adding new requirements there is an indication the unit test is testing more than it should instead of using mock effectively. 17:27:09 nod 17:27:20 * placebo exception 17:27:42 It's necessary for installing test infrastructure (pytest, mock, etc.) and for supporting existing unit tests, but we should carefully consider adding new requirements for unit tests. 17:27:53 test/units/module_utils/aws/test_aws_module.py 17:27:56 21:from pytest import importorskip 17:27:58 29:importorskip("boto3") 17:28:00 why not importorskip? 17:30:03 That's fine if we decide it's OK for the tests to have those dependencies. 17:30:45 I meant "instead of `pytest.skip`" 17:30:50 two separate thoughts, sorry 17:31:38 mattclay: a bit related, some of our network integration tests do stuff like 'pip install pexpect' and stuff like that, wondering if we should have a requirements.txt under folder test/* somewhere 17:31:44 mattclay: indeed, it seems there is a problem with this test. it seems ncclient is not using mock properly 17:31:50 ryansb: that seems doable. 17:32:08 rcarrillocruz: It's fine for the integration tests to use tasks to install their requirements. 17:32:34 https://docs.pytest.org/en/latest/skipping.html#skipping-on-a-missing-import-dependency 17:33:19 rcarrillocruz: I considered adding requirements.txt support to integration tests, but then we'd still need to use tasks for requirements in more complex scenarios. 17:33:59 I think at very least require to have those tasks in prepare roles 17:34:22 That's entirely up to the test. Some tests need to install and uninstall requirements during the tests. 17:34:53 If you have common requirements across multiple integration tests it makes sense to handle that in a prepare_* or setup_* role. 17:36:20 rcarrillocruz: I think it's OK for tests to install what they need in targets/prepare_* 17:39:11 https://github.com/ansible/ansible/blob/devel/test/units/modules/network/f5/test_bigip_device_trust.py#L22-L42 17:39:52 So in that case i think pytest.skip is cleaner 17:40:48 #topic Open Floor 17:40:55 Anyone got anything else? 17:41:00 o/ 17:41:09 I have a few general questions about some new tests I'm writing. 17:41:19 sdoran: Sure 17:41:31 Tests for include/import: I have five total "targets" 17:41:45 I most likely want to share roles and/or tasks between them. 17:42:16 Should I put them all in one target, or have five separate targets with a "clean" way to share resources between them? 17:42:34 sdoran: What are the tests for? 17:42:56 I didn't know if we had precedent for targets that share resources, and thus a common place to put things before I go making something up. 17:43:21 sdoran: If they're all for include/import, put them in a single target. 17:43:22 https://www.irccloud.com/pastebin/eXiPeenY/ 17:43:46 Yes, all are for import/include 17:43:54 You can of course split up the role into as many different files as makes sense within that role. 17:44:02 * gundalow has to ditch now 17:44:35 I need to run playbook since I can't test everything inside a role. I'm using `runme.sh` to do that part. 17:44:40 In the case of modules we generally want 1:1 relationship between target and module. 17:44:49 Ok. 17:45:00 For something like import/include put all the related tests in a single target. 17:45:06 So it won't be too messy to have five tests worth of code at one target? 17:45:20 Because it will most likely have a lot of playbooks. 17:45:38 No, just organize your playbooks within the target so it's easier to work with. 17:45:48 Ok. 17:45:52 That's all I have. 17:46:18 If the targets take a long time to run, that would be a reason to split them up, as a matter of convenience. 17:46:18 Thanks, as always! 17:49:42 Does anyone else have anything to discuss? 17:56:24 Thanks for coming everyone! 17:56:26 #endmeeting