Apply scenarios with a decorator

Bug #1283628 reported by Thomi Richards on 2014-02-23
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

This is a wishlist - I'm posting this here to get feedback on my proposal before I start hacking.


I'd like to be able to apply scenarios to a single test without having to create a new test case class every time. Currently if I have something like this:

class WidgetTests(TestCase):
  scenarios = [('name', {})]

  def test_one(self):

...and I want to add another tests that need a different list of scenarios, my only recouse is to create a new class ('EvenMoreWidgetTests'). This is not such a common problem when using scenarios to test different implementation backends (as is suggested in the testscenarios documentation), but I find testscenarios to be a useful tool to parameterise tests.


I would like to add a decorator that can be applied to a test function that would apply one or more scenarios to that test. Some examples follow:

class WidgetTests(TestCase):

  @add_scenarios([('name', {})])
  def test_one(self):
This would add a single scenario to 'test_one'.

class WidgetTests(TestCase):
  scenarios = [('foo', {}), ('bar', {})]

  @add_scenarios = [('one', {}), ('two', {})])
  def test_one(self):
This would leave 'test_one' with four scenarios, essentially doing the same thing that 'multiple_scenarios' would when given the two scenario lists.

Is this feature possible, and if written, would it be considered for inclusion into testscenarios? Is there any guidance you can give me on writing this?


Changed in testscenarios:
assignee: nobody → Thomi Richards (thomir)
Robert Collins (lifeless) wrote :

That sounds like a fine thing to have.

Changed in testscenarios:
status: New → Triaged
importance: Undecided → Wishlist

Adding notes from IRC, so I don't lose them. I'm looking at this again, having gotten stuck trying to unwrap decorators from function objects. WIll take another look now.

Notes from IRC:

[15:14:30] <lifeless> done
[16:19:44] <thomi> heh, ok. Thanks :)
[16:20:23] * Channel #subunit created on 2009-09-08 09:58:34 UTC
[18:18:18] <lifeless> thomi: as for impl pointers, i tshould be pretty straight forward
[18:19:08] <thomi> lifeless: I had a quick look - My approach was to store a different attr on the test instance, since I need to keep the scenarios set by the decorator separate from the ones set by the class
[18:19:14] <thomi> err "class attr"
[18:19:53] <lifeless> thomi: so the problem you'll have is that method decorators run at method invocation
[18:20:00] <lifeless> thomi: which is after setUp and tearDown have run
[18:20:12] <thomi> ahh, of course
[18:20:16] <thomi> that's unfortnate
[18:20:26] <thomi> that's kind of terminal, isn't it?
[18:20:41] <lifeless> thomi: so what you actually need to do is change apply_scenario to look for the decorator and DTRT at that stage
[18:21:01] <lifeless> thomi: leaving the decorators actual impl as a no-op pass-through
[18:21:01] <thomi> I see. that'll be interesting :)
[18:21:17] <lifeless> you'll also need to unwrap arbitrary other decorators in principle
[18:21:26] <thomi> haha
[18:21:29] <lifeless> enjoy your dive through function object internals
[18:21:31] <lifeless> :)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers