Unit tests in TDD part 1

Unit tests

Unit tests are the quickest, easiest to write and cheapest to run. They generally test one outcome of one method at a time. They are independent of the Android framework.

The System Under Test (SUT) is one class and you focus only on it. All dependencies are considered to be working correctly — and ideally have their own unit tests — so They are mocked or stubbed.

This way, you have complete control of how the dependencies behave during the test.These tests are the fastest and least expensive tests you can write because they don’t require a device or emulator to run.

They are also called small tests. To give an example of an unit test, consider a game app.The Game class is one of the main classes.

A common use case is to increment the score using a function like incrementScore(). Whenever the score increments and exceeds the highscore, it should also increment the highscore. A simple and incomplete definition of the Game class can look like this:

Now go to write test this function:

If you run this test, you’ll see the test doesn’t pass. We now have our failing (red) test. You can then fix this to get our passing (green) test by writing the actual method for the Game class:

now if we can run test again we will find it is pass

Note

Google, in its testing fundamentals documentation, also suggests Robolectric for local unit tests. Robolectric simulates the Android runtime, it allows you to test code that depends on the framework without using a device or emulator. This means that these tests run fast because they run using just the regular JVM of your computer, just like any other test that uses JUnit and Mockito. However, some may consider Robolectric as an integration testing tool, because it helps you test integrating with the Android framework.

#InTheNextArtical we will write Unit Test for all case can you needed. in three sections