search

olexale / bdd_widget_test

A BDD-style widget testing library
MIT License
101 stars 30 forks source link

Bug with Background and support for "tear-down"? #5

Closed kentcb closed 4 years ago

kentcb commented 4 years ago

Hi,

Flutter apps that include timers need to ensure those timers are stopped before the widget test completes, otherwise you get the dreaded:

image

For now, I am working around this by including this final step in my scenarios:

Then the application is torn down

In my case, this involves dispatching a TearDown Redux action so that, for example, middleware that has started a periodic timer can stop that timer.

But the problem is now all my scenarios need to end with that step, and it won't make a lot of sense to a business user reading the specification.

It would be nice if I could specify some behavior to execute at the end (and start?) of every scenario. I thought that Background was this exact thing for adding steps that execute at the start of every scenario, but it instead generates code inside setUp which does not have access to the WidgetTester (and therefore fails to even compile). I assume this is a bug?

Anyway, if the steps in Background were actually inserted within the testWidgets call (which I think was the intent judging by the docs), then should there be a counterpart to Background that executes at the end of every scenario? That would solve my problem.

olexale commented 4 years ago

Hi,

Background behaves as expected as the setUp function accepts callback without WidgetTester. I don't think it will work correctly in case the developer will run separate tests if we'll add a WidgetTester to the parameters, but I haven't tried. In my tests, I usually do service-specific operations (like mock set up) in the Background, and all UI specific steps incapsulate in step like Given the user is on the Registration page which "know" how to navigate to this page.

I followed the Gherkin Reference to make syntax compliant with the original. Unfortunately, there is no After or similar keyword to tear down tests. I solved this by shifting the responsibility from the tear down to tear up and during the test initialization I intentionally override everything. I suppose that this is not an option for you as you have a timer. The only solution I may see from the top of my head is to introduce the After keyword, which will behave almost identical to the Background but will use tearDown function instead.

Thanks!

olexale commented 4 years ago

tearDown function is supported via the After keyword in v0.1.6. Unfortunately, due to test package entities know nothing about WidgetTester, it doesn't accept tester, but you should be able to stop the timer in the store with it. Could you please check whether it fixes the issue?

olexale commented 4 years ago

This should work now, hence I'm closing the ticket. Feel free to re-open it if it's needed.

yonjans commented 2 years ago

Is it possible to run tearDown when there is a test failure in the middle of scenario?

olexale commented 2 years ago

No, as it is not possible to use WidgetTester in the tearDown function so I expect many folks will not get why it is not possible to just move some a step to tearDown. That is why I intentionally dropped support of setUp and tearDown.

My proposition: instead of cleaning up things after test failure, you may re-create everything from scratch during test start. If you think it will not work for you - please share the exact scenario when tearDown is 100% needed.