Guidelines for testing at the right layer

Start with the component level tests first
Always start with the lower level first and then move to the higher level. API testing should be the first to be automated through Unit tests. These tests are easiest to write and most robust of all the test layers as they have the smallest surface area for false failures. Getting test access to the core logic of the component is the key to this strategy and will need some upfront work to investigate ways of hosting your component in isolation. Work with your developers to address this as part of your testability plan. Tests written at this level should provide depth testing for features.

Pros

• Very easy to write, modify and maintain tests
• Tests run faster
• Near zero timing issues
• High level of coverage

Cons

• Upfront work to enable component isolation
• Not a real world environment

Object model tests comes next
These tests are at the higher level than component level tests and are suited for automating the scenarios and integration tests for your feature.

Pros

• Easier to write, modify and maintain tests compared to UI tests
• More closer to real world environment 
• Less prone to timing issues

Cons

• Need to provide testability hook (via private interface) for areas not exposed by public object model (DTE)

UI tests comes last
The complexity of interacting via the user interface for testing can quickly dwarf the complexity of verifying the logic being accessed. Furthermore, any changes to the user interface can have a devastating impact on the tests. Hence, avoid testing through UI as much as possible. UI should be tested separately and shouldn’t be used to test the core functionality of the feature (business logic). Write UI tests for testing the UI elements in a feature. Also some of the end to end scenarios should be automated using UI automation as that’s a real simulation of how the customer would be using the product/feature.Wait till UI becomes reasonably stable before starting to automate these tests.

Pros

•  Closest to real world environment and real world usage of the feature

Cons

• Extremely prone to timing issues
• Usually causes maintenance nightmare