Most discussion and arbitration about testing comes down to the anemic way programmers talk about interfaces.
We say all the right stuff, but then skimp on the details. "Program to the interface, not the implementation!" Oh, but, what then is the interface?
An interface should be understood as the minimal set of things one may expect to be true about some collection of related abstract types.
- The methods for creating/introducing and destroying/eliminating values at these abstract types
- The expectations around identity (memory model as relevant)
- Universal properties that must hold (for *all* situations like this, the following will hold)
Test specification is a component of naming your interfaces. In that sense, it's wild that test specifications don't live in the same place as interfaces most of the time.
Note that test specifications are not necessarily executable. I can say "for all integers n and m, n x m = m x n" as a test specification, knowing that this is probably not feasible to actually test exhaustively. A test implementation may be partial, limited.
The point of this is that it translates the question of "what test should I write?" into "how do I design interfaces, the expectations I allow of users?". The latter is a dramatically better thing to be spending your time thinking about. In my opinion, it subsumes something like 80% of the discussions people have around testing best practices.
This originally meant relying upon the public declaration of functions and methods rather than implementation details. Over time this has been warped to mean the "interface" keyword in OO languages.
I prefer to code to the non-keyword-interface. Turning everything into a keyword-interface has zero value add and causes a proliferation of shitty keyword-interfaces that are not actually points of extension and polymorphism, which is what keyword-interfaces should be. So I would actually say they add negative value to a codebase.
Agree and disagree. As often is the case, once you make an abstract concept concrete in the codebase it gets distorted and exploited. "Keyword interfaces" as you helpfully define here are a prime example. They are not 1-to-1 with genuine "interfaces" as one would like to discuss.
More than just the declaration of functions and methods, though, is the way that those functions are known to interact! Consequentially, an interface may infect another interface, at least abstractly.
In contrast to what I just said above, I think OCaml has a fantastic "keyword" implementation of interfaces. The whole language is built around it. It's not perfect (there's no way to specify the "laws" between interface elements) but it treats composition of interfaces as a very first class idea. I find myself recommending it all the time.
I'm dealing with this a lot lately. Namely having to work within a spaghetti of procedural code...told to use bizarre global scope variables disguised as static classes (Java).
Wading through it all and making proper tests is so much more difficult than it needs to be. The messiness of even determining what's going on seems to reflect the inability to think about interfaces and construct objects accordingly.
This is simple stuff. Java's got tons of standards, and none of them are used.
We say all the right stuff, but then skimp on the details. "Program to the interface, not the implementation!" Oh, but, what then is the interface?
An interface should be understood as the minimal set of things one may expect to be true about some collection of related abstract types.
Test specification is a component of naming your interfaces. In that sense, it's wild that test specifications don't live in the same place as interfaces most of the time.Note that test specifications are not necessarily executable. I can say "for all integers n and m, n x m = m x n" as a test specification, knowing that this is probably not feasible to actually test exhaustively. A test implementation may be partial, limited.
The point of this is that it translates the question of "what test should I write?" into "how do I design interfaces, the expectations I allow of users?". The latter is a dramatically better thing to be spending your time thinking about. In my opinion, it subsumes something like 80% of the discussions people have around testing best practices.