If they have eggs, get six
What am I missing?
It always reminds me of that old joke:
My wife said: "Please go to the store and buy a carton of milk and if they have eggs, get six." I came back with seven cartons of milk. She said, "why in the hell did you buy seven cartons of milk?"
"They had eggs"
Or, while we're at it:
A programmer goes out to get some dry cleaning. His wife told him, "While you're out, pick up some milk".
He never went home.
Humans have an innate ability to understand context and parse information relative to that context. Machines lack this skill entirely. Machines do what you instruct them to do, and don't care about whether the overall intention of your instructions can be understood or not.
Because of this, when given the exact same text to parse, humans and machines will not always take away the same information from it, and that's the main reason why you can't just define an arbitrary language that explains specifications for all parties involved without any ambiguity.
Arguably, programming languages are already our best attempt at doing so. But machines require such pedantic detail that the resulting language is complex and requires experts trained in reading it (software developers). Developers can't even decide on which programming language we should universally use, let alone that we're going to be able to define a specification language that everyone (including machines) innately understands without requiring a particular skillset or training.
Don't get me wrong, we are definitely streamlining the process. If you compare third-generation languages (C#, Java, ...) to the much older second-generation languages (Assembly), the human readability factor has increased tremendously. But we're not at a point where it maps to plain English, it still requires specialized training. Maybe we'll get there someday, but not right now.
Non-developers generally cannot make heads or tails of modern-day programming languages, and this is the main reason why your proposed specification language cannot exit; because it's those non-developers that make the business decisions and define the specifications that applications should adhere to.
Developers are the necessary translation between non-developers and the machine.
My first response to your question was to try and explain that unit/integration testing does exactly what you're asking for. But you mention integration testing yourself, so you must be aware of that.
Unit/integration tests are the tests that are meant to confirm that the library does what its specifications say that it does. All it requires is for a developer to boil these requirements down to actual test code.
I assume the basis of your question is "why do we need to translate specifications to code? Why not write in a way that both humans and machines innately understand?", which I already addressed in the previous section.
One more thing:
Why stop there?
Your question asserts the feasibility of defining a specification language that can be understood by man and machine, without any ambiguity or inconsistency. I've already addressed why that assertion is incorrect, but let's for a second entertain the idea that it were feasible.
Why would you stop at specification testing? If we have this language, then this language can similarly be used to write the application itself, meaning that programming languages would become obsolete, in favor of human-readable specification language which the machine can (allegedly) parse and understand with no issue.
Don't forget that the main purpose of a developer is to be the expert translator who "reads the sacred text" (i.e. the programming language).
The specification language you're proposing is the equivalent of having a translation dictionary between English and the sacred language that is so absolutely perfect that anyone who only speaks English is able to perfectly communicate in the sacred language (and vice versa) without any specialist training.
If that dictionary were to exist, then you no longer need to rely on your sacred translators (i.e. software developers) and you can cut out the middle man entirely.
In short, the specification language you're asserting that can exist is the essence of software development in and of itself.