For every new piece of code written the chances are that old things may break and new features may have some bugs. That could lead to vulnerabilities and instability in the code. To ensure that the development of an application does not get hindered. Hence, It is important to write automated tests to ensure the software created by developers is fit for its purpose

Another crucial point to writing tests is to definitely include those that are expected to fail, like giving an invalid input that will cause an exception in the app. That's because it gives clarity on the cases where passing the test indicates that the action failed as it should, and potentially avoids future hidden issues even with passing tests.

Project Progress

I started my project by creating the base test suite classes and various utility classes for ease of reproducing tests. I also cleaned the existing tests to inherit from the base test to follow DRY principle in the testing code.

I worked on writing various Unit Test suites for viewmodels and other core business logic classes. I installed and used Robolectric custom runner to write tests for those classes which depend on Android as a Library. For test doubles, I went by a mock approach and used Mockito as the Mocking framework for our unit tests. Its verification syntax is neat and so can be used to write readable tests. While checking the app codebase, there were few dependencies on Android as a library (like AsyncTask, Context). In these cases, we don’t need to access Android as a Runtime environment, yet our unit tests fail because of the default stub. That's why roboelectric is best to use with these libraries as it uses real, not mock objects for the Android SDK. Robolectric allows a test style that is closer to black-box testing, making the tests more effective for refactoring and allowing the tests to focus on the behavior of the application instead of the implementation of Android.Besides mocking every Android code, we could run our test on the Robolectric test runner.

I used expresso and mockito to write UI tests. UI tests launch an app (or part of it), then simulate user interactions, and finally check that the app reacted appropriately. They are integration tests that can range from verifying the behavior of a small component to a large navigation test that traverses a whole user flow.

Challenges faced

The project goals that took longer than expected is writing test for asyntask classes and UI tests where the data isn't static or provided by a datastore but from a custom class that uses AsyncTask to fetch I/O data from odk internal file and parse it to return locales in the form of List and maps. I could have solved it by using powermock to mock the static methods, however powermock doesn't currently run in android tests - github.com/powermock/powermock/issues/1062 or create a file by my own with the dummy contents so locale can be set.

Conclusion

Discussing your doubts with mentors and peers gives u a lot more insight into how to solve the bug than figuring out yourself for hours.