Best Practice #4: Ease Your App Testing by Splitting Tests into Smaller Units

Separate Tests for Perfect Test Execution

The application quality has a direct relation to the long-term success of your app. This can be measured in terms of number of installations, user ratings, their reviews and engagement, and eventually user retention. Today’s app users expect high-quality apps and even more so if they spent any money on those.

A better app can go a very long way and the formula for the success is relatively straightforward:  your better quality app will translate to higher ratings, that translates to better ranking, that translates to better visibility in app market, and eventually gets your app more downloads. This cycle of impression-installation-ranking speeds itself up, and your app either ends up being awesome or – awful.

In this blog we’ll take a look at some of the testing tips and tricks that can make the difference for your app. We’ve discussed quite a lot about the importance of test automation, starting testing as early as possible during the development, and using the most robust platform for testing – those real devices. This time we’ll focus on getting your test cases right – not only in size but also in coverage.

Smaller Test Case is Better

When something fails in your huge test case all of your test can fail. With smaller entities results will be separated and some test cases will go through.


Some people are the fans of huge, highly detailed and all-covering test cases.  For some types of apps those work, but it takes some time to create and maintain those types of enormous test cases. Three things should be considered when figuring out the best types of test cases for your app:

Smaller test cases are easier to create, maintain, read and modify

Smaller test cases can boost a creativity of testers. Smaller, focused test cases are easy to produce and maintain as the focus of those test cases is limited compared to large ones. Inputs and outputs are also simple and failing any part of test is easy to observe. Also, smaller test cases are easier to debug and also understand by less tech-savvy team members.

Scope of testing is more accurate with small, targeted test cases

Those test cases are meant to be small and can be quickly created. Number of test cases is high while outcome of one test case can seem irrelevant. However, by combining these results can give you much better covered overall test of your app. For this, you need to create a lot of those test cases and a tool like Testdroid Recorder is truly indispensable.

Small equals for better reusability and easier to extend your arsenal of test cases

Ideally, test cases should have full access inside an application and test all aspects of it: memory contents, data tables, file contents+system, and all internal program states to determine if the app is behaving as expected. For these, smaller test cases work better as they are focused on certain aspect of your application. Those smaller test cases are also easier to reuse – directly or with modifications – as there are less dependencies to other resources.

Easier to Split


Smaller unit tests can ensure that your app gets thoroughly tested and works as intended. Despite you do significant refactoring those smaller test cases are more likely reusable, and are ready for testing. Having a high number of test cases also means better coverage as anything can go wrong in large test cases and then rest of the test is not valid anymore. Here are some preparations to consider:

Plan – And Split!

There is no need to overlap or complicate your test cases. Before jumping into implementing those, plan your test cases and split them into scenarios. Every scenario should be created in a separated test method. As far as possible write your test cases in such a way that you test only one thing at a time. This will significantly help creating well-targeted, accurate and reusable test cases for your app.

Get Your Test Cases “Atomic”

A well-written test case could be described with five characteristics: Accurate, Efficient, Traceable, Repeatable, and Reusable. As long as we test only functions or interactions with no side effects, creation of those test cases is really easy. Then it can get more challenging when your app has side effects but nevertheless, smaller is always easier to handle, implement, get rid of unused scenarios and is also faster.

FIRST – Fast, Independent, Repeatable, Small, Transparent

Your test cases should be very fast to implement and execute. All of those should be independent as well and easily to be repeated. Repeatability also means that your test case should be ready to be executed at any time and doesn’t require any other test case.  Also, result should be always the same – no matter how many times executed, what are preconditions and so on. Smaller test case also makes your test more predictable and obvious for what purpose it was created.

More information about how to create test cases in different methods and change those, plus much more can be found from


As an old compiler guy, shorter, smaller test cases are obvious to me. Smaller test cases have made the testing so much easier – despite the number of test cases can be sometimes huge. Nevertheless, smaller test cases work better in today’s mobile apps. As a summary:

– it’s easier to handle smaller test cases (finding bugs, fixing tests)
– it’s easier to get rid of unused scenarios
– it’s easier to focus on just one thing at a time (test case should test one simple functionality)
– small test cases are faster, so users can more quickly focus on failed ones
– it’s easier to make them to test independent things
– code is cleaner as users have organized structure of their test cases

To learn more about this, please take a look at resources here.

Happy Testing!