#5 - BLoC Testing - Why do you hate testing? It's actually pretty amazing!

hey what is going on everyone i'm wicked and today i will introduce you to block testing and not only that but application testing in general why is everyone so afraid of testing what are the pros and cons and why is it so important to test every feature of your app we'll discuss it all today so without further ado let's get right into it but beforehand here's a content overview of what we're going to cover up today and the specific timestamps so why do developers hate testing so much well the answer i'm always receiving is so simple we hate testing because the application works fine without it it seems like a reasonable answer right and indeed it is an application can work perfectly fine without testing but that doesn't mean we should disconsider it so badly testing is in so many cases a lifesaver it's the hero nobody talks about on the news so if you hate testing that much think of it as a cute little dog which will be loyal to you and your application all the time think of it as a layer of security a layer which will bark whenever something breaks inside your app now let me ask you something have you ever worked on a big project in which you wanted to add a new feature and you realize that after 2 or even 3 days of work despite the fact that the feature works perfectly fine it breaks other features in a completely different place inside your app or maybe have you thought if you ever want to delete a piece of code from within your app will this action be destructive or non-destructive to the app itself how would you check if everything is okay afterwards most of you will say that they will run the app and check every feature to see if everything works well but i'm sure that some of you won't even physically test it and live with the idea that nothing will break a conclusion which is fundamentally wrong code is code and code will break keep that in mind so what if i tell you that there is something which will run a full checkup of every feature you wrote inside your app so that whenever you refactor your code you'll be stress-free without having to worry about if it's gonna crash or not you may have already guessed that i'm talking about our body testing now the difference between the pros and cons becomes rather a problem of deciding whether it's worth choosing testing for its advantages over its disadvantages so obviously we know that the disadvantages of writing tests are that in the first place we need to learn and understand the structure of them and in the second place that it will obviously take more time to implement and write all the necessary code but is it worth it i'll let you answer this question in the following minutes after we understand the structure and practice testing on our beloved counter app so testing how could we implement a test for a feature think of it logically how would you test if something is working or not in big words a test is defined by how you will programmatically tell flutter to double check if the output given by a feature is equal to the expected response you planned on receiving and no other now let's switch to the coding part where i'll show you how testing works and afterwards how to write tests inside your app so in order to follow up you can clone my blog concepts counter project from github because we'll start coding from there the link to that is into description the first thing you should do after you open up the project inside vs code is to go and open up the pubspec.yaml file we already have the flutter underscore block dependency inside but for testing purposes we also need to add both the test and block underline test dependencies to the record now inside our project we need to create a separate test folder in which we'll have all our test files a little hint i can give you is that every feature of your application needs to be tested in the first place so the test inside the test folder should be kind of symmetrical to the features from within your app so all you have to do is to create the folder symmetrically to the lib folder inside the test folder and add the underscore test to the name of the file in this case we'll have a counter underscore qubit underscore test.dart file in which we'll test out the functionality of our counter feature remember from a couple of tutorials back that all the counter feature does is to increment or decrement a counter value based on which button is pressed by the user so inside the test file we need to start by creating a main function inside this main function we'll go right ahead and create a group with the name of counter qubit a group is actually a way of organizing multiple tests for a feature so for example inside our counter qubit group we'll write all the necessary tests for the counter feature in a group you can also share a common setup and teardown function across all the available tests but what is the purpose of these functions inside the setup function you can instantiate for example the objects our tests will be working with in our case we will instantiate the counter block so that we can access it later on in our tests so setup is mainly as its name is implying a function which will be called to create and initialize the necessary data tests will work with on the other hand the teardown function is a function that will get called after each test is run and if is called within a group it will apply of course only to the test in that group inside of this perhaps we can close the created qubit now the time has finally come for us to write our first test which is going to be checking if the initial state of our counter qubit is equal to the counter state with a counter value of 0 we're going to do this by creating a test function and give it a description which should denote the purpose of it in this case it's going to be the initial state is counter state with a counter value of zero so how do we check this well i told you earlier that the purpose of any test is to double check that the output of the feature is actually equal to the expected output and nothing else to do this all we need is the accept function which will take two main important arguments the actual value returned by our initial state and the expected value which we're expecting to be received so our initial state returned when the qubit is created will be counter cubit dot state and the expected value should be a counter state which has the counter value equal to zero we can run this test by typing the pub run test command into the console or rather by clicking the run button next to the group so if we run this test we will surprisingly receive a complete failure with this message in which we expected an instance of counter state and we actually receive an instance of counter state here you can actually start to understand why testing is such an amazing tool it has already signaled us a problem with our app remember that the application worked perfectly when we manually tested it how come that this test fails then well since it tells us that both the expected and actual outputs are an instance of counter state and we know that both should have a zero value inside that means that the instances are still different somehow and that's due to the fact that inside dart language two instances of the same exact class aren't equal even though they are basically identical this is happening because these two instances are stored in a different part of the memory and dart compares their location in memory instead of their values hence making them not equal you can override this behavior really simple by using a really popular library you may have already heard about equatable in the backend equatable is just a simple tool which overrides the equal operator and the hash code for every class that extends it hence tricking dart into comparing the instances by value rather than by where they're placed in the memory so if you want the functionality of comparing two instances like we do in our test equatable is the way to go okay so all we need to do inside our app right now is to add the equatable dependency into the pubspec.yaml file and then extend the counter state class with it note that now we'll get a warning telling us that we need to override the props of the equatable class the props are just a way of indicating equatable which are the fields in our class that we want to be compared while applying the equal operator so we're gonna pass both the counter value and the was incremented attributes inside the props list and now whenever we will compare two counter states dart we'll compare them attributes by attribute in order to see whether they're equal or not so right now if we go back to our test file and run the test the test should finally pass since our expected and actual counter state had the same counter value which is zero now it is time for us to test out the functionality of the increment and decrement functions from inside our counter feature because these are the most important right for this we'll use the block test function from inside the block underscore test dependency we'll use this because we need to test the output as a response to the increment or decrement functions we'll start with the test for the increment functionality so firstly we need to describe it properly the qubit should emit a counter state with a counter value of 1 and there was incremented value of true when qubit.increment function is called to do this we'll use the trio parameters of build act and expect from inside blocktest function the build parameter is a function that will return the current instance of the counter qubit in order to make it available to the testing process the act parameter is a function that will take the qubit and will return the action applied on it which in our case is the increment function the expect parameter is an iterable list which will verify if the order of the states and the actual emitted states correspond with the emitted ones and no other since the counter qubit emits only a single state in this example we'll place it inside the list accordingly the same procedure applies also to the decrement function the only difference being that will act by calling the decrement function and that will expect a counter state with a counter value of -1 instead of 1 since we subtract 1 from the initial counter value let's run all the tests now and as you can see everything passed now we can know for sure that the counter qubit works as it should think about this scenario for example now so let's say you were moved away from this project and another guy comes into place to continue the development he doesn't know dart that well and he thinks that the equatable package is not needed and that the application can work just fine without it so he refactors the code runs the app and indeed the app is still working perfectly but underneath if we run the counter qubit test we can see that if there would be a part inside our app comparing two identical states the output would have been completely different this is exactly why app testing should not be skipped it may seem like the refactoring works fine but in reality it isn't so i guess now you understood why it's worth spending the extra time writing tests for your application this tutorial was a brief introduction on testing but don't worry you will learn much more from the practical examples in the future block based apps will build together from scratch in the next tutorial i'll introduce you to block access which is going to be a follow-up to the block provider part we discussed a couple of tutorials back in which i will cover all the possible ways to provide a single and unique instance of a block or qubit in different scenarios until then if you like this video don't forget to hit the like button and subscribe to my channel because i know you don't want to miss any of the incoming tutorials this was wicked stay safe i'll catch you guys in the next one cheers

Channel: Flutterly

Views: 10,177

Keywords: Bloc, Testing, Flutter, Tutorial, Bloctesting, Concepts

Id: cVru6Gy4duQ

Length: 13min 37sec (817 seconds)

Published: Thu Sep 24 2020