How to Write Good Tests - Android Testing - Part 2

[Music] hey guys welcome back to new video really make sure to watch this video till the end because it will probably be one of the most important videos in this entire playlist since it will cover almost all of the best practices you need to consider when you test your code i want to start to talk about tdd which stands for test driven development and that is basically a development style that highly values testing and the main principle for tdd is that we write our test cases before we write the actual implementation for our functions and we only do this for unit tests so not for integration or ui tests but for unit tests the flow is basically always the same that we first think about the function signature and define the function signature but no content of that function yet then the second step is to write the test case that should test the function and that test case should always fail at first because we don't have any content in that function so the test case must fail of course and after that at the third step we finally implement the function in a way that satisfies our test cases and that is by the way also the style that i will teach you in this playlist so we will write our test cases before the actual implementations of those functions and then another big principle of test driven development is that you should only have a single assertion per test so if you don't know what an assertion is that is basically the actual test so with an assertion we make sure that our test either succeeds or does not succeed so an assertion could be let's say at this point in our test case this condition must be true if it's not true the test case will fail so we could also have several assertions in our test case so for example this object should be null this object shouldn't be null and this object shouldn't be null too so we could have several assertions one after another but this wouldn't really make our test case independent because in test driven development if a test fails we immediately want to know the cause why it failed so we don't want to analyze the test case first to find out what the cause of that failing test was instead we just want to look at the function signature of that test case and immediately see why that test failed or actually what the bug in our program is but sometimes you just can't prevent having multiple assertions and then that's fine so for example if you want to test if your loading properly works so if your loading bar progress bar is displaying then you first want to check if a live data is emitting that loading status and then you also want to assert another time if that live data is emitting another value so the loading basically stops in that case we must have several assertions but you should only have as little as possible all right so now we need to think about which correct characteristics we want to have in a good test case and these three characteristics are the scope the speed and the fidelity of the test case so the scope determines how much of our actual code in our function that we want to test is covered by our single test case then the speed is pretty self-explanatory so it just means how fast our test case runs and now you might ask why is that actually important the importance here is because the faster your test runs the more often you will run your test cases and the more bugs you will eventually find so if your test cases need to make some requests to a server or something like that that just takes time then you're likely to not run them very often so we will actually have other solutions for tests like that and last but not least we have the fidelity which is super important for test cases which just means how close our test case is actually to a real scenario because that's what we want to verify in the end that our app works well in the real world and then next what is also very important is we want to prevent so-called flaky tests what are flaky tests those are tests that sometimes succeed and sometimes fail so you could imagine a test in which you just generate a random number between one and five and then you make an assertion that this number is equal to two so sometimes this test will succeed if that random number is two and sometimes it will fail and of course these tests can also occur not only with random numbers but also with other external things that can happen so you should always make sure that your tests are independent and also that your tests are not dependent on another test case or that any test case affects the outcome of another test case and as a last topic of this video i want to cover how many test cases should we actually write because testing or writing test cases costs us time and that means it also costs us money if we are working on a real app that should make us money and as a general answer you can say we always want as little test cases as necessary but also as many as necessary and i know this answer doesn't help you much so for that we have the so-called equivalent classes in software development it's kind of hard to explain generally but let's actually consider an example so that the concept of equivalent classes gets more clear to you let's take a look at this registration form here so we want to validate the user input of this registration form you want and we want to know how many test cases should we write for that so in the end we want that our test cases together cover the code of our validation function so we say that we take one test out of each equivalent class and an equivalent class could be for example here that we take those those inputs in this registration form that lead to a successful registration so all of these inputs together that lead to successful registration belong to a single equivalent class so that means if we enter a valid username here that is not already taken and we repeat the password correctly then this would lead to a successful registration then it wouldn't make much sense if we would test this once with username peter and once with username carl because if peter succeeds then it's very likely that carl will succeed too so because those two inputs belong to the same equivalent class we only take a single test case out of that equivalent class and we can choose on our own which of that which of those test cases inside of this equivalent class we take to test actually so another equivalent class would be if we would leave our username field empty and submit the form then this of course should lead to an error response but we should test that because that is not covered in our first test case if we enter a valid username and another equivalent class would be if we enter a username that already exists or another equivalent class would be if we incorrectly confirm the password so we write something else in the confirm password field than in the password field so i hope and think you get it we just want to cover all of our code paths with as little test cases as possible because that's what makes good testing possible in the end so i really hope this video gave you a good impression of how you should write your test cases but of course we will cover all of those principles in this series and you will learn how to apply them in practice if you are not a subscriber of my channel yet then quickly make sure to do that click on the subscribe button and make sure to get high quality android content every second day have a wonderful day everyone see you next video bye bye [Music] [Music] you

Channel: Philipp Lackner

Views: 17,700

Keywords: testing, android, test, test case, junit, mockito, mock, fake, stub, tdd, test driven development, intellij, android studio, unit test, unit testing, integration test, integrated test, end to end test, ui test, kotlin, mvvm, live data, coroutines, dagger, retrofit, room, database, roboelectric, android test, jvm, flaky test, development, programming, git

Id: rew86GST0g0

Length: 8min 29sec (509 seconds)

Published: Fri Aug 14 2020