You can cut and slices test automation however you want to.
I usually have tons of unit-tests that rely on the use of mock, a lot of DAO/ORM integration-tests that require some sort of in-memory-DB (I'm fortunate enough that DBs such as H2, HSQLDB, Apache Derby exist in my world) to test queries (that includes DB migration testing).
The unit-tests and integration-tests cover a lot of code-branches (I use EclEmma/Cobertura to view coverage).
I still have full-stack functional tests but they don't have high coverage. They only ensure that the happy-path works.
I love my unit-tests because I can write them immediately without waiting for the DB/Storage to exist or to work.
I love my integration-tests because I don't have to wait until the front-end or some level of business logics are done (my DAOs/Repositories layer are kept minimal, most business logics exist in my Services layer, which are unit-testable).
If I have plenty end-2-end bugs, I'll revisit my strategy.
I usually have tons of unit-tests that rely on the use of mock, a lot of DAO/ORM integration-tests that require some sort of in-memory-DB (I'm fortunate enough that DBs such as H2, HSQLDB, Apache Derby exist in my world) to test queries (that includes DB migration testing).
The unit-tests and integration-tests cover a lot of code-branches (I use EclEmma/Cobertura to view coverage).
I still have full-stack functional tests but they don't have high coverage. They only ensure that the happy-path works.
I love my unit-tests because I can write them immediately without waiting for the DB/Storage to exist or to work.
I love my integration-tests because I don't have to wait until the front-end or some level of business logics are done (my DAOs/Repositories layer are kept minimal, most business logics exist in my Services layer, which are unit-testable).
If I have plenty end-2-end bugs, I'll revisit my strategy.