The testing stage of our development pipeline at work is currently fully non-automated. Our codebase supports a REST api and PHP website. The api was built on top of a legacy MVC PHP application which was initially developed over 10 years ago.
Since I was responsible for building and integrating the api with external clients like a mobile application, I felt that I had no choice but to develop PHPUnit test cases that covered the restful functionality of each api endpoint. However, the underlying website code was not based on a restful schema, but accepted form based requests instead, with many optional and/or conditional fields for input that were passed to a custom undocumented model after being validated by a separate PHP class, and then sent to a view built with angular v1, smarty template and PHP.
Testing the sites custom MVC framework has remained primarily a manual process given the large amounts of legacy code in the codebase. Due to the closed system and lack of documentation, there are currently no feasible paths to fully automating testing.
Personally, I would love to automate testing for all three components of our MVC framework as it would save large amounts of time devoted to bug-fixing and troubleshooting error. However, introducing unit testing to any part of the framework would involve an audit of the current code, followed by large amounts of refactoring in order for any type of test framework integration to be possible. Currently, this is not a cost-effective measure as only approximately 15% of the codebase is updated regularly.
We tried implementing basic testing on the front-end using playwright, an end-to-end test engine for virtual browsers, but the current site was too complex and variable for any automated tests to be of value. Without the use of scriptable templates and the strict enforcement of front-end code via a central javascript library like React, there seemed little point in attempting to automate testing of something that changed drastically from page to page.
Additionally, the small size of the development team made exploring moving to an alternate framework that was automation friendly, currently infeasible. I have suggested creating a project centered around moving parts of the existing codebase into a more structured framework incrementally, but the time investment required isn’t currently sustainable at our team size. However, since we are bringing more developers into the company, this may be something that we revisit in the future.