11–20 of 20 posts
Consider how things might look from the other side: I'm getting a big push from a fellow co-worker to try TDD. He thinks it's the best thing since sliced bread, giving examples of random articles that validate his point of view. I trust him and he is a hard-working person, but in this case I think he doesn't want to get out his comfort zone and at the end of the day, just isn't seeing the bigger picture. I don't want…
> So far my best argument is: "Don't do it for you, do it for the team". What concrete problems are you having that you think TDD is going to make better? Are too many bugs making it to production? Are you not writing enough tests? Are your tests poor quality? I would have a bad reaction if somebody was trying to push TDD on to a project without objectively weighing up the benefits as TDD isn't suitable everywhere. I…
In this case I think TDD or a version of TDD acceptable to the team can really speed up development. I want that feeling if I run all the tests I can deploy.
All devs are remote devs with different timezones.
Earlier quoted context omitted.
The goal is to try it as a team. Having 2 devs on a project with different approaches won't be efficient. The part I strongly believe is that before writing a piece of code I need to know what I am writing. Similar to a task/story, I need to have an acceptance criteria. Knowing to write a test means knowing what are you writing. Thanks for your input.
> The part I strongly believe is that before writing a piece of code I need to know what I am writing. Similar to a task/story, I need to have an acceptance criteria. Knowing to write a test means knowing what are you writing. Is there an existing problem in the team where people don't know what they're writing though?
For Further Information: What is the existing testing strategy (if any)? Do you have QA testing? Etc.
The problem arises when some changes are made and random tests are failing and it becomes more difficult to fix.
Try evaluating pros and cons for TDD on your current project and make a decision together based on them. Currently you're just proselytizing and thinking about only what you like and how you want to work.
TDD can be counter-intuitive for a lot of people, but I think that the most important thing that anyone should be aware about TDD, and you as a Manager/Lead/Overlord should use as your battle cry is that "TDD is all about measuring". Measuring? No! not code coverage, but rather as in real life... If you drink coffee, and you like to add some sugar/milk/gold or whatevs, do you just blindly add a random amount? or do y…
No, I am not TDD nut, which is the opposite of the TDD, from what I understand "write enough code" for the test to pass.
I didn't "get" tdd (even after what I thought was a fair shake) until I paired with a person who was well versed in it. Suddenly, it clicked. It even happened in a code base that I said you can't do tdd in! Even after this great experience, I would not say that tdd is for everyone and for all situations. I like to have some layer of test that I see red then green, and tdd helps with that. But I find tdd _only_ works…
For Further Information: What is the existing testing strategy (if any)? Do you have QA testing? Etc.
We have a good coverage, but we don't have that feeling that after running all tests we can release. Currently each dev decides how much tests to write, but usually after the fact to make sure whatever he wrote behaves as expected, at that time. The problem arises when some changes are made and random tests are failing and it becomes more difficult to fix.
How does it become more difficult to fix? Because you have to fix the tests, too? Don't just fix them. Use them as a guide to where to think a bit more. "This change broke that test. Is that telling me that the change broke the assumptions of that code, and that therefore the change is wrong? Or is it just that the test itself didn't expect this?" You should know which it is before you fix a test.
I think the situation you're describing here is not TDD-vs-after-the-fact-testwriting. It's incomplete-vs-close-to-complete test coverage.
Earlier quoted context omitted.
We have a good coverage, but we don't have that feeling that after running all tests we can release. Currently each dev decides how much tests to write, but usually after the fact to make sure whatever he wrote behaves as expected, at that time. The problem arises when some changes are made and random tests are failing and it becomes more difficult to fix.
No, when some changes are made, very specific tests start failing, and that conveys some information. (It can take some work to sort out what the information means, though...) How does it become more difficult to fix? Because you have to fix the tests, too? Don't just fix them. Use them as a guide to where to think a bit more. "This change broke that test. Is that telling me that the change broke the assumptions of t…
I think and hope with TDD (or some sort of it) to get everyone into a discipline mode, which will lead to better tests. Coverage should follow.
Anyway, I think it's worth trying, but it needs commitment and discipline, similar to agile... it has to be tried as a team.
Consider how things might look from the other side: I'm getting a big push from a fellow co-worker to try TDD. He thinks it's the best thing since sliced bread, giving examples of random articles that validate his point of view. I trust him and he is a hard-working person, but in this case I think he doesn't want to get out his comfort zone and at the end of the day, just isn't seeing the bigger picture. I don't want…
Haha, good one. My goal is just to try it before saying no.