How to write Unit tests in Flutter using the AAA pattern

[@abdulbari7246]

already excited for the advanced version of unit testing😍

[@runtimesnippets]

I am glad you liked it!

[@runtimesnippets]

Working on the next video!

[@TylerCodes]

Hey, this was a really well put together video! Thanks!

[@runtimesnippets]

Glad you liked it!

[@asbahumais655]

Wonderful!

[@runtimesnippets]

Glad you like it!

[@HistoryBits95]

Love it!!

[@runtimesnippets]

Glad you like it

[@lucas.marianno]

Great video again! Would you mind further explaining why loops in tests are a bad idea? Following your other video on TDD, I came up with the following test: ```dart test("return 'Fizz' for multiples of 3", () { // arrange const inputs = [3, 6, 9, 12, 33, 66, 99]; // act for (int input in inputs) { final result = solver.execute(input); // assert expect(result, 'Fizz'); } }); ``` Should I divide it into multiple tests for each input? Wouldn't that be a lot more verbose? What is the correct way of thoroughly testing a functionality? Thanks in advance, you got a new subscriber!

[@runtimesnippets]

1."Why are loops a bad idea in unit tests?" Because 1. loops go against readability and conciseness. 2. The flutter test suite will only give you one output per unit test. So let's say, if your unit test had 7 inputs and one of them was wrong, the entire test will fail. Which is not very descriptive, and doesn't provide you with the right feedback. We also won't be able to know on which iteration the expect method failed. We will have to debug this ourselves. 2. "Should I divide it into multiple tests for each input?" Absolutely! 3. "Wouldn't that be a lot more verbose?" Remember the rule from the TDD video: "Write specific test cases that make your code generic" Meaning: The more specific test cases you have, the more general your code will become in handling different inputs. So it doesn't matter the number of tests you have. One input = One output, and there should be a single test case for that. 4. "What is the correct way of thoroughly testing a functionality?" To thoroughly test a feature, you should identify different edge cases that will break the feature, and then test your code through those inputs. For example, in your method, maybe a multiple of 5 or a multiple of both 3 & 5, might break your feature, so I would test your code with those inputs as well. But be cautious, don't write test cases that keep on testing the same behavior. For example, writing a test case for 3, then 6, then 9, then 12 will keep testing the same behavior of the feature. Once a behavior has been verified, go for different inputs that will test some other part of the method, like 5 or maybe 15. Have any other questions? I would love to answer :)

[@lucas.marianno]

@@runtimesnippets Got it. Thank you! Cheers from 🇧🇷

[@runtimesnippets]

@@lucas.marianno you’re welcome!