[testing] Remove nose usage

[jd]

This has been deprecated and unmaintained for years; stop installing it.

• Replaces nose.tools.ok_ with assert
• Replaces nose.tools.eq_ with assert ==
• Replaces nose.tools.assert_raises with pytest.raises
• Add missing unittest.TestCase inheritance in some place
• Only install requests-mock for requests_contrib scenarios; this modules has a pytest plugin that gets loaded otherwise and pre-load
• requests, making some test checking for module load ordering fail.

[majorgreys]

The one big suggestion I would have here is that we follow use the unittest.TestCase.assert* methods for any test cases we have already moved to using BaseTracerTestCase. That might be a separate PR from this one that removes the dependency to nose though.

What do you think?

PS RIP nose

[jd]

I'd rather suggest to go full pytest and drop (in the long run) unittest usage.

There's no upside of using unittest if you're using pytest here.

• pytest rewrites the assert statement (see doc) dynamically so there's no need to pick the right self.assertXXXX method
• pytest.fixtures are not fully compatible with unittest.TestCase (see https://docs.pytest.org/en/latest/unittest.html#pytest-features-in-unittest-testcase-subclasses)

And some other things listed here.

[brettlangdon]

I'd actually prefer to use base unittest methods over methods/fixtures from pytest, that way we keep pytest as a test runner only so it is easier to swap out in the future if we want (like what happened with nose).

Happy to discuss further if everyone feels that is a silly stance.

[jd]

I guess there are two different things here, the runner and the test framework.

The thing is that — at least in the case of pytest — they are a bit tangled, making it weird to use unittest+pytest, which is actually more considered as a "compatibility mode" from pytest PoV.

That's the main reason that would make me lean towards going full pytest rather than staying in a "compat" world.

Considering pytest usage nowadays, I don't think the trade-off of staying in "unittest+pytest-compat-mode-in-case-the-world-switch-away-from-pytest" rather than the perks of going full pytest is worth it. :)

[brettlangdon]

@jd fair enough. I've always had issues using some pytest features, but I've always tried to mix directly with unittest, probably why I had issues.

I don't have that strong of an opinion here, was just going simple (hell, should we just go with unitest + python -m unittest discover ? :p), if you and @majorgreys agree to go all in on pytest, then that is fine by me.

[brettlangdon]

really hoping you mostly just used sed here and didn't manually update all of these? 0_o

But otherwise, this lgtm.

[jd]

I don't know about that sed tool you're talking about. It took me two entire nights to update this, but it was worth it. I'm a software craftsman and I believe in doing things by hand so I can feel the code.

jk, yeah I used sed. 🤣