With the shift in technology like angularjs, there is a tendency to push the business logic to the UI layer. how is this affecting the testing pyramid?
It’s funny how technology goes around in Circles. One of the first applications I ever worked on, back in 2003, was a rich desktop application (written in the .NET framework) with a lot of UI layer logic, which was replacing an internal web application that had server side logic.
It seems the client side/server side logic keeps moving back and forth, however, the good thing about technologies like AngularJS and ReactJS is they allow developers to write unit and component tests of the UI components, so I think that’s the best approach: lots of unit/component tests of the UI (with as many dependencies mocked as possible – shallow rendering if possible), less or no integration tests, and a handful of full stack end-to-end automated acceptance tests that run in a browser.
Any client side logic, persistence, state and database stuff is interacted with via an API, and this can be tested through its own unit tests (and possibly few API integration tests – but this also can be covered by your UI end-to-end automated tests).
So, my ideal present day automated testing pyramid looks something like this:
Unit tests for client side logic, unit tests for anything done server side, and full stack automated e2e tests that ensure that at all times our key user flows are working as expected.