Its definitely a bad idea writing new code that builds up on your old code, that has not been tested properly, because you quickly have to start debugging multiple layer is code at once.
Its definitely a bad idea writing new code that builds up on your old code, that has not been tested properly, because you quickly have to start debugging multiple layer is code at once.
Test driven development. Having a well designed automated test, and then developing until the test succeeds.
Ah thanks. That sounds like not that bad of an idea, but for the scale that my projects are at thus is quite an overkill. I usually try if it works in The best case sz scenario and then try to deliberately break it by calling certain functions with garbage as parameters.
No project is too small for tests
Tests double as your documentation for your intent
Take it from me who has 20+ years of personal projects behind me, the ones that I’ve kept around are typically the ones that have some form of test suite.
It’s easy to build on something if you know you’re not breaking something in the process
Yeah of course I Am testing. I Am usually just not writing very extensive tests. I try to break it as much as possible with as little effort and try then to prevent it from breaking.
That sounds like you’re doing TDD, albeit informally.
From what I understand the difference between how I code and what has Ben described as TDD in this thread is, that I set up everything first and then try to think of ways people could break the code and then test these vases/try to prevent them.