In Test Driven Android Development, we discuss how good Object Oriented Design and Test Driven Design are complementary. We create a simple JUnit test, using a stub object that represents a data feed. Next, we demonstrate how to write a test driven design unit test for a Java class that performs network operations. After that, we create a unit test for a data access object that uses a JSON data feed. Our test includes JUnit 4 asserts and Hamcrest-style asserst. Then, we discuss blockers that prevent us from writing unit tests, and how we can use Mockito, code coverage, and automatic test execution to ameliorate those blockers. Finally, we look at UI testing with Espresso, and multi-platform testing with Firebase.
About The Author
Brandan Jones has been an Adjunct Assistant Professor for the University of Cincinnati since the 2000-2001 school year. He has taught many courses in programming, from introductory programming to full stack development.
Brandan proposed and created the first Android programming course at the University of Cincinnati, and has been teaching it ever since. He reapplied this course and taught it at Northwestern University’s School of Continuing Studies as well.
Brandan is the creator of the Android app PlantPlacescom Mobile, which allows users to search for plants by color, and GPS plants. He wrote this app in 2012, using TDD principles. He used selected JSON feeds from that app in the examples in this video course.
Brandan’s mix of both academic and professional experience means that he brings real-world concepts to the classroom. Most of his high level classes include hands on experience with unit testing, scrum, and distributed version control systems.
Brandan holds a BS in Accounting and Management Information Systems from Miami University in Oxford, Ohio. He also earned a BS in Horticulture from the University of Cincinnati’s College of Design, Art, Architecture and Planning, and a Masters of Business Administration from the University of Cincinnati, Lindner College of Business, with concentrations in Operations Management and Real Estate Finance.
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.
Packt has been committed to developer learning since 2004. A lot has changed in software since then - but Packt has remained responsive to these changes, continuing to look forward at the trends and tools defining the way we work and live. And how to put them to work.
With an extensive library of content - more than 4000 books and video courses -Packt's mission is to help developers stay relevant in a rapidly changing world. From new web frameworks and programming languages, to cutting edge data analytics, and DevOps, Packt takes software professionals in every field to what's important to them now.
From skills that will help you to develop and future proof your career to immediate solutions to every day tech challenges, Packt is a go-to resource to make you a better, smarter developer.
Packt Udemy courses continue this tradition, bringing you comprehensive yet concise video courses straight from the experts.