4 ms·
My 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 catch
by tspike 10y ago
My 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.
- brightball 10y agoAgree here. Tests the stuff that needs testing.
- candiodari 10y agoThat means you can't use coverage tools, so this approach makes the tests unquantifiable. It is not how most major dev shops work, because of the bean counters and the "senior" developers/leads/managers/... who seem to want nothing but appeasing beancounters. It also produces superior software in my experience.
- brightball 10y agoIt's been very YMMV in mine. For some things, it's indispensable. Others it's tedious, repetitive and of questionable benefit.
- thingexplainer 10y agoIt's tedious and repetitive even when the benefit is obvious and substantial, unfortunately.
- candiodari 10y agoAutomatic test generation tools. There's quite a few on github, but the real ones are the ones you write yourself. What you're looking to do is to run the software a few times and record tests for particular pieces of code during those manual tests.
- flukus 10y ago> That means you can't use coverage tools, so this approach makes the tests unquantifiable. So it's win win then ;)
- err4nt 10y agoCan you elaborate more? Im a frontend guy and sometimes I write JS plugins for the browser (that run after page load, and apply based on how things render on the page, or bawed on user interaction with the page) and non-frontend folks tell me I need tests for my code, or dont want to look at it until I have test. How would I build a tewt for this, other than a functional test that runs in-browser and the test is whether it works or not?
- zachrose 10y agoHere are two strategies. First, you can go "outside" what you've built, simulating a user's interaction and examining the resulting DOM. In general this is a tool-centric approach. Another approach is to partition your code into what Gary Bernhardt calls an "imperative shell" of code that touches the outside world and a "functional core" that does not. Then unit test the functional core, which shouldn't require special testing libraries, and validate that the imperative shell works by the occasional manual or "outside" test.
- z3t4 10y agoFirst off, if your code don't have bugs, then that is preferable! In my experience with front web dev the issue has always been different (old) devices. Testing could be done by browser macros that simulate input, like mouse movement, click on x, y, z, etc. Then take screen-shots to see if something is off. You can also make your widgets throw errors (1) and call home via XMLHttpRequest if an error is detected. 1) http://www.webtigerteam.com/johan/en/blog/error_driven_development.htm http://www.webtigerteam.com/johan/en/blog/error_driven_devel...
- hliyan 10y agoExactly my experience - I've done TDD for 3 different types of calculation functions in 3 different languages over the years, and all were beneficial: financial risk calculations in C++, report data calculations in PHP and billing calculations in JavaScript. On the other hand, TDD for operations that involve I/O (including user interactions) were not helpful at all.
- gohrt 10y agoYou are saying "TDD" but your comment reads the same if you just say "tests in general"