How do you deal with 3rd party integration usually?

I like to keep it at arm’s length as much as possible. I don’t object to using third-party utility libraries like the Apache libraries, but if possible, I like to wrap them up behind a facade of some kind so that we can:

• Change to a different implementation if we want, without having to make wider changes.
• Choose to drop the library and provide our own implementation.

I try not to supplement the facade with our own code, or create facades that talk to more than one library if I can.

What are your thoughts on his suggestions for handling public APIs?

Well, oddly enough, I agree with pretty much everything in this chapter, which might be a first. Although I did get a good ironic chuckle about using Log4j as an example, given that at the time of writing the world in in a panic over a recently-discovered zero-day exploit in Log4j.²

In the Android applications I’ve worked on we’ve used slf4j³ to handle our logging, but in all the applications I’ve recently worked on we’ve also added an additional layer of abstraction between logging and self4j! This might sound like overkill but it’s repeatedly paid dividends as we’ve experimented with different ways of doing logging over the years.

Unfortunately, some libraries are so integral it can be difficult to abstract away the implementation. This is especially true for libraries that generate code at compile time such as Dagger, Android Room or Retrofit. In such cases the best you can do is isolate what you can, and take great care before making a commitment to using these libraries. They’re much harder to move away from.

Do you agree or disagree with Martin’s assertions about testing in this chapter?

Martin makes many claims in this chapter about the value of tests. The core of the argument is that tests are a primary part of the codebase that require proper design and maintenance. In doing so, the tests will give developers confidence to make changes, as the developer can rely on the tests to help identify problems when making changes.

Test code is just as important as production code. It is not a second-class citizen. It requires thought, design, and care.

It is unit tests that keep our code flexible, maintainable, and reusable… If you have tests, you do not fear making changes to the code!

This is an argument I’ve made throughout my career, and in my experience I’ve found it to be generally true. Martin makes a clear case that tests need to be designed and clean, and discusses what happens if they’re not. A missing facet of that argument is that if a project gets handed over to another team, what Martin calls ‘Dirty’ tests will make them all but useless to the new maintainers.

I speak from experience. I once inherited a complex project that had been handed off to multiple teams. When we got it, it did come with a suite of tests. Unfortunately the project, having gone through so many teams, was a mess of different designs and disciplines. We had no idea if the tests worked, or if the code the tests targeted were even still “valid” code paths in the application.⁴

It would have been great to have had a suite of tests that we could review to form a better understanding of how the application worked, and it would have helped give us confidence to make broader changes.

We want to test a single concept in each test function. We don’t want long test functions that go testing one miscellaneous thing after another.

This is something I completely agree with, but it took me some time to learn. One of the reasons I struggled with this earlier in my career is that the IDE can usually generate a ‘stub’ test class for you, that will create one stub per function. This implies a workflow of:

1. Write the class.
2. Generate a Unit Test Stub.
3. Fill in the blanks in the Test Stub.

This is a terrible approach that didn’t serve me well. It’s much better to write smaller tests that target a specific concept. A concept in this case might mean the happy path, edge case, invalid input, etc. Each test should verify that in a given scenario, the expected output is produced.

What makes a clean test? Three things. Readability, readability, and readability. Readability is perhaps even more important in unit tests than it is in production code.

As I mentioned in previous articles, I am a very strong believer in readability. I agree with Martin. Readability is critical for unit tests. I even gave a presentation fairly recently talking about this subject, where I suggested various ways tests could be made more readable. Some of the suggestions I made included:

• Use longer test names that include the action and the expected behaviour.
• Always prefer to create your test data inside the test method.
• Use ‘magic’ embedded numbers and strings so you don’t have to go looking to find out where a value is set.
• Use named constants to describe test data where it can improve readability (e.g. MAX_TIME_TO_LIVE_IN_MS is much easier to understand than 65536).
• Be far more lenient about DRY violations in Unit Tests, as we want each test case to be independent.

So, broadly, I do agree with most of the claims made by Martin. The main claim I don’t agree with is about Test-Driven Development (TDD).

[The principles of TDD] lock you into a cycle that is perhaps thirty seconds long. The tests and the production code are written together, with the tests just a few seconds ahead of the production code.

My experience with TDD is that it works in some things and doesn’t in others. In the places where it does work you might, if you’re good and write a non-complex bit of code, achieve the flow state⁵ described by Martin. In practice, it is often the case that your code is too complex or nebulous to permit tests to be written up front.

I once did a project entirely using a TDD approach. While the tests were enormously helpful, I also found myself in some cases in a spiral of writing the tests, then the code, then having to go back to update those tests after moving on to the next part of the code. By the end I’d deleted more tests than I’d written due to this. It felt like I’d wasted a lot of time.

Even so, I still agree that TDD has a place. I agree with Martin that writing the tests after the code can lead to code that’s hard to test, and encourages you to skip testing altogether.

Do your tests follow FIRST principles?

FIRST is defined as:

• Fast
• Independent
• Repeatable
• Self-Validating
• Timely

The first 4 of these are properties of the tests themselves (mostly), while the last is a property of the development approach. I try to write tests that are fast, independent, repeatable and self-validating. But there’s caveats.

In the Android world, some tests require a device. These are generally called instrumented tests. We can write more “standard” unit tests as well, as long as nothing in those tests depends on anything in the Android runtime (which is frankly quite a lot). Then there’s a middle grounds, an emulated Android device on which you can run Instrumented Tests, or an emulated Android Environment⁶ on which you can run Unit Tests.

Instrumented Tests are slow. They’re slowest on an emulated device. In the real world, android devices have different versions and features. How much for this can really be accounted for in tests? It gets really tricky when you encounter a test that runs on real hardware but fails on the emulator (or vice-versa). Sometimes it’s because of the SQLite library version, or ability to recognise a file format like webp.

So sometimes, the reality of Android development is that writing Fast and Repeatable tests is actually very hard. I do what I can, and try to write tests that will run on multiple environments, but it’s not straightforward.

As for Timely, I won’t lie. Despite my best efforts, it’s not easy to write the tests first in practice. Usually, writing Unit Tests is a post-hoc activity.

What is the normal approach you take to writing tests, and what do you think are the pros and cons of this?

The tests I write generally follow the guidelines Martin has set out here. I write smaller Unit Tests that target specific concepts and I make an effort to maintain these tests. If a bug is discovered in a class that has Unit Tests, I add a Test Case that targets covers that specific issue.

The issue isn’t the tests that I write, it’s whether the tests get written at all. Martin would probably argue that tests quickly pay for themselves. That the time it takes to write tests is recouped in the time saved fighting bugs and performing maintenance. Maybe that’s correct, but in my experience there is always pressure to deliver something that seems to work and then to move on to the next thing.

The issues with this are pretty obvious. I recently had some code that appeared to be working most of the time, but had some odd behaviour. I added a comprehensive test suite and found:

• It had bugs on certain input conditions that I hadn’t spotted.
• I hadn’t considered what to do on certain invalid inputs. In writing tests, I was forced to codify the response to invalid input.

Even after writing the tests, a bug was discovered that wasn’t covered. I went back and added 3 more test cases, one for the bug and 2 more for related behaviours. These tests were crucial to fixing this code.

I could have just tried to debug the code and fix the problems, but writing tests was the appropriate approach. Perhaps if I’d used TDD I’d have found these issues earlier. I am committed to writing more and better tests. I fully understand the value they provide. I’d even argue I’m a pretty strong advocate for writing tests. It’s just that sometimes, in the real world, the pressure on a developer to deliver functionality means that the tests just don’t get written. Even for someone like me, who fully understands what I’m missing out on.