Write tests as you go?

This is great if you can. Ideally if you have all the pieces of your puzzle laid out and you've whiteboarded the sequence diagram this should be feasible and good policy moreover. In my experience I am usually struggling to figure something out as I code leading to an impracticality for test-as-you-go. I had a conversation with a coworker over lunch about this a few days back and just yesterday we paired on something we didn't understand fully from the outside looking in and the thing I am thinking of just did not lend itself to test-as-you-go. Abstractly you could do all the fact-finding and then turn around and do some whiteboarding, but by the time you've proved out the fact-finding you already have a lot of code written. In a tech a talk I can't fully remember I recall a speaker suggesting that you should really test as you go as if you just plan to write the tests at the end of your work you will find yourself with surprising frequency in challenges in which you work up to a deadline, barely get something done, and then skip the tests. That is kinda my experience too. I can think of jobs I had which fit with as much and as much basically leads to sparse testing that does not allow for the safeguard one needs to make sweeping changes. It becomes easy to break stuff when refactoring and thus there is a reliance on a testing team that TDD purists are able to escape somehow. So is sparse testing, testing only the really core logic or testing here and there, worth doing at all? Is it like doing Scrum (not LSD, i.e. Lean Software Development) with point estimates and Fibonacci cards without any burndown chart to make the calculated velocity matter or screwing up an estimate have consequences? No. It is still worth doing. Every developer should intermittently write tests if they can't do it consistently. With testable code comes good code, and specifically I mean dependency injection. I am the rare developer who has never written any C++ but I am hip to what goes on therein in procedural messes with dependencies reached out to midstream in lieu of being handed in in an OOP (object-oriented programming) manner. I've heard the stories let's say. In contrast, in the environments where I've done C# with minimal testing StructureMap is the norm and everything that we write that we don't test is something that we could test. The separation of concerns associated with the S of the SOLID principals is pronounced. The exercise of architecting something that is going to have a few tests in its Hello World phase to begin with is hence a really smart move.