In this chapter, you learned that integration testing focuses on the scope of UIs or APIs exposed via your services to test the full stack of your code. It requires setting up the database, executing the code to be tested, and querying the database. These tests are critical to ensuring that all the components of your application deliver the expected behavior.

This chapter also introduced unit testing. Here, you learned that in order to make individual code components, classes, and methods as robust and future-proof as possible, developers can test each method in isolation without incurring the overhead of setting up the database or updating it. As such, unit tests run more quickly. Unit tests can increase coverage, as more corner-case testing scenarios can be emulated using the mocking of scenarios that would otherwise be impossible or difficult to set up on the database.

One key lesson of this chapter was that unit testing requires an understanding of some other patterns, such as dependency injection and mocking. Dependency injection can be implemented in a number of ways, using constructors, factories, and setter methods. The approach you use for dependency injection will depend on your personal preference and/or the preference of the libraries you're using. Multiple approaches to dependency injection can be combined if needed.

In this chapter, we learned that one way of implementing dependency injection is to use Apex interfaces. Utilizing multiple implementations of interfaces that represent the boundaries between the dependencies of your code base allows you to implement the real code and the test code separately. Mocking is most effective when the code being tested is not aware of which implementation is being used. We then looked at examples using the Apex Stub API and Jest API methods, which allow the creation of dynamic mocks for classes without using interfaces. The summary we arrived at was that the Apex Stub API is good for existing code bases or scenarios where using interfaces doesn't make sense or adds overhead.

This chapter also introduced ApexMocks, a mocking framework library that reduces the work involved in building mock objects, removing the need to physically code them. Based on Mockito, it offers advanced facilities to configure mocked method responses or throw exceptions to help test error handling. This framework also records the mock methods invoked and provides a sophisticated matching syntax to assert which methods were called. The Apex Commons open source library used in this book utilizes the factory pattern to provide built-in methods for injecting mock implementations of the Service, Unit Of Work, Domain, and Selector layers. Additionally, this chapter introduced Jest, which is a mocking framework library for JavaScript and has been embraced by Salesforce to aid in writing Lightning Web Components unit tests. Unit testing client components, in addition to traditional browser automation testing, has become important as richer user experiences have become common, which has necessitated more component-based thinking.

In summary, my advice is to appreciate that, in the end, unit testing and its associated prerequisites make it a difficult concept to master and requires a lot of work upfront. Start with a few simple examples at first and continue leveraging your existing testing approaches until you're ready to expand. Once you have mastered the APIs and best practice principles, it becomes second nature and can help open up access to other development coding practices, such as test-driven development.

In the next chapter of this book, we will take a step back and look at how to scale your development around multiple developers and set up the continuous and automated execution of your tests whenever changes are made.