So the idea with TDD is that you write the minimal amount of code that makes the tests pass, right?
And the tests passing are supposed to make me feel good?
Well then it doesn't work because I know my code is wrong and will cause issues further down the line and I can't not feel bad about it.
> ... the idea with TDD is that you write the minimal amount of code ...
In my experience, both the "test code" and "actual code" have to bent over backwards to allow for (unit) testing, especially when your "actual code" is side-effect heavy.
Anyone that had to `stubClock.advance(5, MINUTES)` can relate.
@wolf480pl In that case a "spec check" is actually a nice thing to have, expecially if you anticipate multiple implementations. Makes it easy to judge how much of a feature set is available.
E.g. kaitai-struct has a set of checks [1] for different languages it's implementer in, for you (user) to see what features work and (language implementer) to see what needss fixing.
[1] https://github.com/kaitai-io/kaitai_struct_tests/tree/master/spec
@wolf480pl It might actually be an advantage then. Have your "spec checker" receive a host:port argument and run a barrage of tests against it using the public API.
The next step would be exposing it as a public service, a-la https://federationtester.matrix.org/ :)
@michal yup, that's the plan long-term.
After I finish prototyping and write down the spec.
Wolf480pl
Michal 
