When it comes to testing the Apex code, we know the drill: Write good tests to cover your code, assert its behavior, and obtain at least 75 percent coverage. Force.com will not allow you to upload packaged code unless you obtain this amount or higher. You also have to cover your Apex Trigger code, even if it's only a single line, as you will soon see is the case with the implementation of the Apex Triggers in this book.

However, when it comes to unit testing, what Force.com currently lacks, however, is a mocking framework to permit more focused and isolated testing of the layers mentioned in the previous sections without having to set up all the records needed to execute the code you want to test. This starts to make your Apex tests feel more like system-level tests having to execute the full functional stack each time.

While conventions such as test-driven development (TDD) are possible, they certainly help you think about developing true unit tests on the platform. Doing so can also be quite time consuming to develop and then wait for these tests to run due to growing data setup complexity. Such tests end up feeling more like system- or integration-level tests because they end up testing the whole stack of code in your application.

The good news is that the layering described in this book does give you opportunities to isolate smaller tests to specific aspects, such as validation or insert logic. As we progress through each layer in the upcoming chapters, we finish with an entire chapter focusing on implementing a true unit testing approach using an open source mocking framework known as Apex Mocks. It has been shared with the community by FinancialForce.com and is heavily based on the Java Mockito framework. https://github.com/financialforcedev/fflib-apex-mocks.