oh, whoops, I meant "Test Driven
Development", my bad. Anyway, the basic idea is before you even start writing any of the actual code for the project you write some tests for the code.
I know this sound backwards but bear with me.
Obviously those tests are going to fail right out the gate; but what we do have is a set of requirements that defines how the code should work. So we start coding to start making these tests pass. So if we have a set of 10 tests, we work on making that first test pass. Once that test "turns from red to green", we move on to the next one. Code that doesn't affect whether a test pass or fails gets tossed. Once our first set of tests are all green, we write more tests for new functional requirements, and we repeat the process.
I find writing the tests first give me a firmer idea of what I need to do for a project. Reading old tests and writing new ones also tend to give me bursts of inspiration. It also tends to keep me on track, ("ok, I've got these 3 specs I need to turn green"). The test also help me when refactoring, because I can find if and where I broke something while refactoring relatively quickly. As a project grows in complexity, and different components need to integrate with other components in increasingly complicated ways, the tests also help find places your code might fail that you did not expect.
|Also would you be willing to be my pair buddy for programming?|
I'd like to, but I can't. Between my full time job, and the startup I'm trying to get off the ground with a few partners (buddy programmers you could call them even), I just don't have the time to pair up with someone else. I'm sure there's someone else on this forum that would love to either have a partner for one of their projects, or join up with you on one of yours.