Food for thought: while TDD can be useful in many projects and scenarios, sometimes it isn't practical (or even possible).
For example, at work we're creating an animation engine, a large part of which must be carefully designed and constructed before tests are even a possibility. While testing must be a part of that project, TDD itself is a stumbling block to progress there.
By contrast, in creating a language parser, TDD is absolutely essential to ensuring it meets expectations and works well.
I absolutely agree that programming is not a science, and it certainly isn't engineering. However, no methodology exists which fits every project well. Each methodology has its place, and its usefulness should be considered purely in the light of the needs of each project. To apply it because "It's the One True Methodology" is invariably asking for trouble.
I agree sometimes it's hard to TDD and is not a bad practice write tests shortly after production code (however I think it's important keep small iterations between production and tests).
I don't know in other countries but here (I'm talking about Spain), Computer Science degree it's officially called "Computer Engineering" !!!).
Small iterations and testing are both excellent things to do - although the definition of both "small" and "testing" vary from one situation to the next. (i.e. there are some cases where you must manually test, because unit tests do not provide adequate coverage by nature of their design.)
I agree, "computer engineering" and "computer science" (the degree name in the U.S.) are total misnomers. (See my article, The Cake is A Lie.)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Food for thought: while TDD can be useful in many projects and scenarios, sometimes it isn't practical (or even possible).
For example, at work we're creating an animation engine, a large part of which must be carefully designed and constructed before tests are even a possibility. While testing must be a part of that project, TDD itself is a stumbling block to progress there.
By contrast, in creating a language parser, TDD is absolutely essential to ensuring it meets expectations and works well.
I absolutely agree that programming is not a science, and it certainly isn't engineering. However, no methodology exists which fits every project well. Each methodology has its place, and its usefulness should be considered purely in the light of the needs of each project. To apply it because "It's the One True Methodology" is invariably asking for trouble.
I agree sometimes it's hard to TDD and is not a bad practice write tests shortly after production code (however I think it's important keep small iterations between production and tests).
I don't know in other countries but here (I'm talking about Spain), Computer Science degree it's officially called "Computer Engineering" !!!).
Small iterations and testing are both excellent things to do - although the definition of both "small" and "testing" vary from one situation to the next. (i.e. there are some cases where you must manually test, because unit tests do not provide adequate coverage by nature of their design.)
I agree, "computer engineering" and "computer science" (the degree name in the U.S.) are total misnomers. (See my article, The Cake is A Lie.)