Most academic software projects that I work with are very different from code developed by professional developers. There is frequently no unit testing. I work with projects that fall into three broad classes:

1. local programs.
2. web apps that are light clients that do almost nothing except call an API.
3. web apps that do extensive client side work and that interface with external databases.

Testing is normally done by live testers. This is useful for ensuring that the system runs and identify UX issues but testers may not identify issues where the code functions but delivers results which are not entirely correct. Live testing is also not easily replicable. Absent unit testing we are frequently faced with doing end-to-end testing. Even with unit tests there are several reasons to try to build an end-to-end test suite. An end-to-end test suite in its simplest form is a collection of inputs and expected outputs. For testing CLIs and APIs this is normally just a spreadsheet of input parameters and expected output. For GUI apps and web apps this means a list of actions within the app and then an expected output and will require a testing framework (such as selenium or BrowserStack) . There are several reasons to build such a test suite

1. there is unlikely to be a proper software requirements specification for an academic project. A end-to-end test suite explains what the researcher understands as correct functioning. As the “specifications” evolve we add new test lines that capture the new functioning and revise the old ones as necessary.
2. as with classic test suites, as we make maintenance or performance changes to existing code we can check that the code continues to function as expected.
3. these test suites serve as excellent performance test suites for profiling tools.