Make use of unittest setUp tearDown methods

[niloct]

Hi,

I'm currently using your tool, and managed to leverage unittest assert methods, which is really nice, even though behave's source code doesn't do this (they use hamcrest methods instead).

I've face an issue though: even when I subclass from unittest TestCase, methods like setUp and tearDown aren't called by the steps.

Did you think about this usecase ?

(Just trying my luck on this first issue report, hope you reply).

Thank you.

[spyoungtech]

Hi @niloct thanks for opening this issue. I think this might be a case where you need to draw a distinction between what is provided by behave, behave-classy, and what can be provided by unittest when running tests defined in the behave framework.

Perhaps the README could be less misleading about its example using unittest.TestCase -- when inheriting from TestCase it is mostly for the benefit of the methods you can leverage inside of your test methods, like self.assertTrue or similar. TestCase could be easily replaced with any other common component.

However, this wasn't meant to imply that you could integrate all features of unittest into a behave test execution just be inheriting from TestCase. Normally, the test runner is responsible for running the setUp/tearDown methods. However, behave's test runner has no knowledge/intention to run these methods, so they are not run.

The responsibility of behave-classy is pretty small at the moment. It's just for getting your methods from (a single instance of) your class registered as step implementations. Everything within your methods is run during the execution of particular steps. Anything that happens outside of a particular step would probably be outside the scope of the responsibility of behave-classy at least for now.

For sake of argument, let's say you could define setUp and tearDown in behave-classy and have it work somehow... There arises a question of where the setUp/tearDown should run. Because the step registry is just a collection of step implementations and not necessarily tied to any particular lifecycle, it's not clear to me at what moment during the test execution you would want the setup/teardown to run -- per feature? per file? per scenario? per step?

Anyhow, I think your best option at the moment would be to use behave's native hooks (e.g., before_all/after_all, before_feature/after_feature, etc.) and/or fixtures to replace your use case for setUp/tearDown.

If you have a specific use case for this, I could maybe help fill in some gaps of how to implement it or maybe think of some ways behave-classy could be modified to help.

[niloct]

Hi Spencer,

Thanks for the detailed response and attention!

I thought for a while about the correct moment to run the aforementioned methods. Do you think it's fair to assume they must wrap each test method (i.e. step) of the class which had its register() method called ? Subclassing may impose some food for though on this, but it's a start.