Learning Path: Android: Test-Driven Android App Development

This video gives an overview of the entire course.

As a project falls behind, the items at the end of a development cycle are the ones most likely to get skipped. Thus, it’s important to write tests first.

GUI at the top, integration in the middle, and unit tests at the bottom. Unit tests are the most important, so they get the most space in our testing real estate.

Behavior-driven design is a way we can communicate universally across disciplines. This communication allows us to understand the requirements of the software we want to create.

How unit testing specifically relates to Android, and how Android projects are structured for unit testing.

Discuss Java and Object Oriented Design best practices, why we use interfaces, how to create data transfer objects, UI, business logic, and DAO layers.

Many hobbyist programmers don’t understand why we should use interfaces. The first part of understanding interfaces is understanding polymorphism: the variable type tells us what methods we’re allowed to call, and the object type tells us what will happen when we call those methods. Interfaces decouple the variable from the object type and allow us to easily change the object type.

When developing in layers, a Data Transfer Object (DTO) can be used to transfer data across layers. DTOs are simple Plain Old Java Objects (POJOs) that are generally a collection of attributes with getters and setters. In this video, we show how to create a DTO.

More details on what each layer does, what belongs in the user interface, what belongs in the business logic, and what belongs in the data access layers. We’ll show with examples.

If tests feel like a necessary evil. But they can make unit test coverage exponentially more difficult. Discuss how good object-oriented design minimizes the need for if tests, and how that makes testing easier.

Discuss fundamental JUnit frameworks: Fixtures, Test Suites, and Test Runners. Create a simple JUnit test with @Before and @Test annotations.

JUnit 4 takes advantage of many annotations to enhance our test and allow us to create tests as Plain Old Java Objects (POJOs). In this video, we explore several JUnit annotations.

Demonstration of runtime JUnit annotations: @Before, @BeforeClass, @After, @AfterClass, and @Test.

Test-driven design creates a good design. We consider what is unnecessarily redundant in our program. The more we can do with less code, the less we have to test. In this section, we model our program, and refactor it using ArgoUML.

Test-driven design means that we write a test before writing the class we’re going to test. In this video, we create a test for a simple NetworkDAO, watch the test fail, and then build the NetworkDAO until the test passes.

Describe a history of BDD. Discuss how BDD relates to specifications.

Using the requirements document from 4.1, we create our first given-when-then BDD and TDD unit test in this hands-on example. Discuss the prerequisites and syntax.

Expand on our BDD unit test by adding more examples from the requirements document, defined in video 4.1.

Become a JUnit expert by exploring more JUnit 4 asserts: assertEquals, assertNull, assertNotNull, assertTrue, assertFalse, and more.

See assertEquals and assertNotNull asserts in a hands-on example.

Hamcrest offers us a new assert framework where we can write tests in a flexible, readable, and natural language format. Hamcrest asserts are ideal for collections and String comparisons.

Use Mockito to mock out dependencies. This removes excuses for why we can’t do unit tests.

Demonstrate Mockito with a hands-on example.

When you take short-term shortcuts that create long-term problems, you’re creating technical debt. If left unaddressed, technical debt results in additional development work.

Unit test code coverage is a quantitative measure of technical debt. Code coverage shows the percentage of code covered and the percentage not covered. The percentage not covered is technical debt.

One reason we neglect writing unit tests is that we simply forget to run them. If we make running compulsory, just as automatic builds are today, we will see results immediately and be motivated to write our unit tests.

Instrumentation tests run using the JUnit framework and have access to Android framework classes as well, such as Context and Parcelable. Instrumentation tests are ideal for functional and UI testing.

Show how to write, execute, and debug an instrumentation test with a hands-on example.

Espresso is a new framework that allows you to easily record instrumentation tests with a running Android emulator and a UI test recording widget. This allows the author to write and execute tests against complex components, like a ListView.

Show how to write an Espresso test with an example.

The Android ecosystem is complex, and we must account for this complexity in our tests. We can use several tools, including Firebase, to assist us in this testing.