How disable print in test async_redux?

[LeandroMoura3]

Hello,

I wanna to do all tests in my project, but I have a lot of prints of the async_redux lib.

I can disable this prints? This is very helpfull, but I wanna know if it this can be disable too.

Thanks for the package.

[marcglasberg]

Both the Store and the StoreTester constructors have a parameter called testInfoPrinter.

You can disable prints by providing a dummy testInfoPrinter to the StoreTester:

var storeTester = StoreTester(testInfoPrinter: (_){});

I will add this information to the docs.

[dluksza]

Even if you add testInfoPrinter parameter you'll still get New StoreTester. printed to the console.

[marcglasberg]

Yes, and I also think it should be easier to turn off these prints. Having to pass testInfoPrinter everytime a StoreTester is created is not very nice. I'll find a better solution.

[dluksza]

I don't mind flipping the default behavior, so that nothing is printed, as long as you don't provide testInfoPrinter

[marcglasberg]

See version 2.6.0:

You can now disable all prints globally by making StoreTester.printDefaultDebugInfo = false.

You can also change the print functions globally, since they are not final and private anymore.

[dluksza]

I don't think that this is the best solution. My app state consist of 7 separate state objects that are tested independently. In order to disable prints I need to set global prihntDeraultDebugInfo seven times (once in each test class) in order to disable it everywhere.

Also having this as a global can lead to unpredictable results depending on the order in which test are loaded.

I would rather prefer to change the default behavior of StoreTester constructor.

[marcglasberg]

@dluksza Changing the default behavior of the StoreTester constructor would only create the same problem for those who want it to have the opposite behavior. So I picked the most common, which is to leave this turned on. If tests fail, or if you want to develop with TDD or BDD, the prints must usually be turned on.

Global variables are meant as global configuration. They are there to let you set a default that shouldn't be changed while the program is running. You should pick your default and set it in your test's setUpAll method, for example. I don't see how this would lead to differences depending on the order in which test are loaded. They will all use the same default.

setUpAll(() => StoreTester.printDefaultDebugInfo = false;

[dluksza]

For me logging from tests is an anti-pattern. Especially right now with dart/flutter, if you have a fair amount of tests for your store (lets say 300+) then when one of them fails you don't see which one is it. This is partly because flutter test doesn't print summary of failed tests, it only shows number of passed, skipped and failed. When you have a lot of print outs (logs) from your test you also need a fair amount of terminal buffer and scrolling to see what actually failed.

For TDD or BDD assets should be your source of truth, not logs. Of course logs can help with debugging some bugs. But you should mostly relay on the asserts.

I was going to argue that flutter tests by default run all tests in parallel and having global shared state between parallel tests will lead to unpredictable behaviors. But, it seems that tests are run in isolates and each isolate have its own set of globals. At least I wasn't able to get more print outs than I expected during my quick testing.

It all depends what is your expectation. If you like to always see the logs in tests, then with the approach you took there is no changes to be made in your code.

On the other hand if you (like me) prefer to see which test had failed without scrolling through ton of logs. Then this is not the best approach, since setUpAll needs to be added in every single test file that uses StoreTester.

[marcglasberg]

Yes, it depends on your expectation, and there's no way to make it perfect and please everyone. At least now it's possible to turn all printing off, and it's still easier than adding testInfoPrinter to each StoreTester constructor, right? Also, that's not the only configuration you can have. You can also set the global timeout so you may need a setupAll anyway.

I disagree that logging from tests is an anti-pattern, specially when we're talking about the kind of complex integration tests that the StoreTester allows. But you may be right for simple unit tests.