It may not boost productivity upfront, but it saves a lot of time down the line by alerting you when something is out of place.
An External Replication on the Effects of Test-driven Development [pdf]
11–20 of 332 posts
Re: An External Replication on the Effects of Test-driven Development [pdf]
#12As someone who uses unit tests to find bugs in my code, that I would never otherwise find, this is surprising.
That not TDD, though. It's more similar to test-after.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#13Could it be that TDD vs. tests-after-code is a highly personal thing? I personally find it easier to write good tests after I've coded something functional. Before hand, I know one or two fuzzy ideas of what I want to accomplish, but I can't list out the concrete, real-world test scenarios until after I've coded something, poked and prodded it, etc. But I know some people are wired differently; they'll think a lot mo…
> if it works for you and your coding style, awesome. But don't force it down my throat or act like it's the One True Path to clean code. This applies to so many things in Software Development - text-editors, variable names, plugins, architectures, operating systems...
...life
Re: An External Replication on the Effects of Test-driven Development [pdf]
#14My experience has been that TDD is worthwhile when working with notoriously slippery whack-a-mole functions like handling time or money. The time saved by catching regressions vastly outweighs the time taken to implement the tests.
In contrast, TDD has been a waste of time for me for UI-based work, as the effort needed to properly expose the functionality under test is too great and the requirements and design change too quickly to be worth it.
In the latter case, writing some deterministic UI tests against mock data after the requirements and implementation have settled has proven much more effective in preventing regressions.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#15It may not boost productivity upfront, but it saves a lot of time down the line by alerting you when something is out of place.
No, that's the value of automated regression test. TDD is just one way to skin that particular cat.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#16I never really viewed TDD as better at reducing bugs for a short term project, its going to have marginal better chances of getting additional test cases.
I view it more as important for breaking the growth of testing effort in an iterative project. With each release the scope of what should be tested to fully test a project climbs and unless a team wishes to linearly increase the size of its test team its all but certain tests will be skipped.
TDD gives us the ability to always full regression test as its just machine time. Its a safety factor in knowing nothing is broken which in turn gives us confidence we can refactor.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#17Re: An External Replication on the Effects of Test-driven Development [pdf]
#18As someone who uses unit tests to find bugs in my code, that I would never otherwise find, this is surprising.
It's not about TDD vs no tests. The article is about tests first or tests later.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#19My experience has been that TDD is worthwhile when working with notoriously slippery whack-a-mole functions like handling time or money. The time saved by catching regressions vastly outweighs the time taken to implement the tests. In contrast, TDD has been a waste of time for me for UI-based work, as the effort needed to properly expose the functionality under test is too great and the requirements and design change…
Agree here. Tests the stuff that needs testing.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#20...when implemented poorly