3 add meaning of TDD acronym
source | link

I understand the benefits of testing your code as you go along, but why compiling?

But how will you test your code as you go along when you don't compile accordingly?

The extreme case is TDDtest-driven development (TDD). It is obvious that TDD does not work with your strategy, since TDD means extremely short cycles of write-test, compile (should fail), write-code, compile again, run-test, fix-bugs, compile again, refactor, compile-again, run-test, and-so-on...

So not everyone does TDD, at least not always (me too, I admit). With your current strategy, you will never have a chance to even try TDD. But even when you are not doing TDD, it is IMHO extremly helpful to test your code more regular - which is not possible when you don't compile it regularly. And when your test fails, you have running to debug it (which can help you to understand why the nice looking algorithm you have written some minutes before does not behave so nice as you thought it should do). And the more code you write without compiling, the more code you write without testing, so the more likely it will happen that you run into a case where you cannot predict that the time to fix the problem is "O(1)", as you wrote.

I understand the benefits of testing your code as you go along, but why compiling?

But how will you test your code as you go along when you don't compile accordingly?

The extreme case is TDD. It is obvious that TDD does not work with your strategy, since TDD means extremely short cycles of write-test, compile (should fail), write-code, compile again, run-test, fix-bugs, compile again, refactor, compile-again, run-test, and-so-on...

So not everyone does TDD, at least not always (me too, I admit). With your current strategy, you will never have a chance to even try TDD. But even when you are not doing TDD, it is IMHO extremly helpful to test your code more regular - which is not possible when you don't compile it regularly. And when your test fails, you have running to debug it (which can help you to understand why the nice looking algorithm you have written some minutes before does not behave so nice as you thought it should do). And the more code you write without compiling, the more code you write without testing, so the more likely it will happen that you run into a case where you cannot predict that the time to fix the problem is "O(1)", as you wrote.

I understand the benefits of testing your code as you go along, but why compiling?

But how will you test your code as you go along when you don't compile accordingly?

The extreme case is test-driven development (TDD). It is obvious that TDD does not work with your strategy, since TDD means extremely short cycles of write-test, compile (should fail), write-code, compile again, run-test, fix-bugs, compile again, refactor, compile-again, run-test, and-so-on...

So not everyone does TDD, at least not always (me too, I admit). With your current strategy, you will never have a chance to even try TDD. But even when you are not doing TDD, it is IMHO extremly helpful to test your code more regular - which is not possible when you don't compile it regularly. And when your test fails, you have running to debug it (which can help you to understand why the nice looking algorithm you have written some minutes before does not behave so nice as you thought it should do). And the more code you write without compiling, the more code you write without testing, so the more likely it will happen that you run into a case where you cannot predict that the time to fix the problem is "O(1)", as you wrote.

2 added 194 characters in body
source | link

I understand the benefits of testing your code as you go along, but why compiling?

But how will you test your code as you go along when you don't compile accordingly?

The extreme case is TDD. It is obvious that TDD does not work with your strategy, since TDD means extremely short cycles of write-test, compile (should fail), write-code, compile again, run-test, fix-bugs, compile again, refactor, compile-again, run-test, and-so-on...

So not everyone does TDD, at least not always (me too, I admit). With your current strategy, you will never have a chance to even try TDD. But even when you are not doing TDD, it is IMHO extremly helpful to test your code more regular - which is not possible when you don't compile it regularly. And when your test fails, you need ahave running program to debug it (which can help you to understand why the nice looking algorithm you have written some minutes before does not behave so nice as you thought it should do). And the more code you have writtenwrite without compiling, the more code you write without testing, so the more likely it will happen that you run into a case where you cannot predict that the time to fix the problem is "O(1)", as you wrote.

I understand the benefits of testing your code as you go along, but why compiling?

But how will you test your code as you go along when you don't compile accordingly?

The extreme case is TDD. It is obvious that TDD does not work with your strategy, since TDD means extremely short cycles of write-test, compile (should fail), write-code, compile again, run-test, fix-bugs, compile again, refactor, compile-again, run-test, and-so-on...

So not everyone does TDD, at least not always (me too, I admit). But even when you are not doing TDD, it is IMHO extremly helpful to test your code more regular - which is not possible when you don't compile it. And when your test fails, you need a running program to debug it. And the more code you have written without testing, the more likely it will happen that you run into a case where you cannot predict that the time to fix the problem is "O(1)", as you wrote.

I understand the benefits of testing your code as you go along, but why compiling?

But how will you test your code as you go along when you don't compile accordingly?

The extreme case is TDD. It is obvious that TDD does not work with your strategy, since TDD means extremely short cycles of write-test, compile (should fail), write-code, compile again, run-test, fix-bugs, compile again, refactor, compile-again, run-test, and-so-on...

So not everyone does TDD, at least not always (me too, I admit). With your current strategy, you will never have a chance to even try TDD. But even when you are not doing TDD, it is IMHO extremly helpful to test your code more regular - which is not possible when you don't compile it regularly. And when your test fails, you have running to debug it (which can help you to understand why the nice looking algorithm you have written some minutes before does not behave so nice as you thought it should do). And the more code you write without compiling, the more code you write without testing, so the more likely it will happen that you run into a case where you cannot predict that the time to fix the problem is "O(1)", as you wrote.

1
source | link

I understand the benefits of testing your code as you go along, but why compiling?

But how will you test your code as you go along when you don't compile accordingly?

The extreme case is TDD. It is obvious that TDD does not work with your strategy, since TDD means extremely short cycles of write-test, compile (should fail), write-code, compile again, run-test, fix-bugs, compile again, refactor, compile-again, run-test, and-so-on...

So not everyone does TDD, at least not always (me too, I admit). But even when you are not doing TDD, it is IMHO extremly helpful to test your code more regular - which is not possible when you don't compile it. And when your test fails, you need a running program to debug it. And the more code you have written without testing, the more likely it will happen that you run into a case where you cannot predict that the time to fix the problem is "O(1)", as you wrote.