External vs Internal Quality

More information from Growing Objected-Oriented Code Guided by Tests. The book talks about external vs internal quality. External quality is how well the system meets the needs of its customers and users (is it functional, reliable, available, responsive, etc.). Internal quality is how well it meets the needs of its developers and administrators (is it easy to understand, easy to change, etc.).

It goes on to talk about how the different types of tests fall into these categories

Running end-to-end tests tells us about the external quality of our system, and writing them tells us something about how well we (the whole team) understand the domain, but end-to-end tests don’t tell us how well we’ve written the code. Writing unit tests gives us a lot of feedback about the quality of our code, and running them tells us that we haven’t broken any classes—but, again, unit tests don’t give us enough confidence that the system as a whole works. Integration tests fall somewhere in the middle.

I am not sure what type of test you would call our tests. My guess is it would be acceptance tests. The focus of our tests are mainly on making sure the software does what we would expect it to. The focus of our tests has not been on making sure the internal structure of our code is clean.