From time to time, development teams need to replace back-end architecture and when doing so they need to ensure that the application’s front-end functionality remains the same. These projects can vary in size, from short projects to long-running pieces of work. This process contains risk as the backend unit tests passing does not guarantee that the front-end functionality the customer experiences still works. Creating failing automated front-end tests that initially fail, as in test-driven development, can help reduce this risk.
Test-driven development (TDD) is a development practice that has been called “test-first development”[1] because the tests are written before the code is written. The tests written in TDD are usually unit tests. These tests will fail until code is written that makes them pass. Kent Beck describes TDD as “an analysis technique, a design technique, really a technique for structuring all the activities of development”.[2]
If the backend of an application is changing the development team will want automated tests to ensure that the front-end functionality still ‘works’. Most teams have front-end tests that are automated via the UI and run on Continuous Integration (CI). The front-end tests are usually written using tools such as Cypress, Playwright, Ghost Inspector or Selenium that run tests against the UI. These tests can be used to help backend developers to test front-end functionality. It would be normal for the backend architecture replacement to be done behind a feature flag. If this is the case, initially, when the feature flag is applied to a branch all or some of the existing front-end tests will fail. The back-end development team then has failing front-end tests that they need to get to pass and keep passing.
As well as using the existing front-end tests to support back-end development, it can also be helpful to create new tests that test areas of functionality affected by the back-end changes. These new tests can be created against the main branch. The new front-end tests will probably fail when they are first run against a branch that uses the feature flag for the new back-end development. The development team will need to get these new failing front-end tests to pass on the branch with the feature flag and then keep them passing.
It is useful if the back-end developers can run the tests themselves. This can be done in a number of ways such as a command line or by using GitHub actions.
The development team may fear that their backend changes will break some front-end functionality, TDD can help because it “is a way of managing fear during programming”[3]. Using front-end tests to support back-end development by creating failing tests that the team then need to get to pass and then keep passing can be described as test-driven development. It can be described as TDD because the front-end tests are written before the code and code needs to be written so that the tests pass.
References:
[1] Test-Driven Development: By Example by Kent Beck (2003, p203)
[2] Test-Driven Development: By Example by Kent Beck (2003, p204)
[3] Test-Driven Development: By Example by Kent Beck (2003, pxi)
TestAndAnalysis 