t. user who never developed a single piece of software
and no ricing arch and writing shitty scripts does not count as developing software
What do anons think about test driven development?
Agreed, writing tests before the code implies you know what the API/spec of your code should be, which is rarely true.
E.g. if I'm refactoring some private functions, then I will write the new version, iterate until I'm happy with the API of the new version (i.e. it's simpler and results in simpler code where it's called) and the existing tests pass, then write tests for the new function.
The same is true with user facing APIs except I will iterate on sample user code.
This is pretty much what I've been thinking lately.
Write code -> Write tests while I refactor -> Optimize and/or Simplify
It seems to me that TDD makes the most sense when you're refactoring because by the time you're refactoring you know more or less what your functions are going to do but you haven't started iterating on functions yet. TDD is really made for makeing iteration easier.
Coming from the QA side, TDD is fan-fucking-tastic when you have developers on a SOA application, particularly in the case of microservices. I only end up with the difficult fun problems in those cases not the fucking retarded curry-niggers who write shit code and don't even test it. Don't be a curry nigger.
It needs to be zero-cost during runtime.
github.com
Architecting based on known requirements will give you a good enough idea of what the API/spec should be before starting.
You shouldn't be writing tests for private members, friend isn't something that should be used often.
TDD makes the QA process far more efficient, every thorough test written results in the relevant piece of code not needing to be manually checked for regressions every merge (unless the spec changes).
A good build system will run code linters and all sorts of tests and benchmarks on a variety of hardware configurations and reject anything which doesn't meet standards or regresses the codebase.