2 ms·

It's not always possible (or even advisable) to document with a test; to take two trivial examples from recent memory, one was a wrapping bug in IE 11 and the o

It's not always possible (or even advisable) to document with a test; to take two trivial examples from recent memory, one was a wrapping bug in IE 11 and the other was a typing issue with TypeScript. These issues required comments, not tests. (Granted, for the IE11 bug the ideal test harness would include a Win/IE virtual machine in a known state along with a good robot control and the ability to check screen geometry, but as of 2019 that's science fiction)

couchand 8y ago
Your second example is a great example of how sometimes it's just not worth it. You're probably right that it makes sense to just write a comment and move along (after you've replicated the bug and filed an issue against the TypeScript compiler). Eventually it will get fixed, your team will upgrade their system, and you can remove the workaround. I'd argue the first example illustrates my point quite well (but forgive me if this gets too ivory tower). It would seem highly unlikely that the wrapping bug is intimately coupled with whatever else the component is doing. It will likely come up again in some other situation, in this project or another. After all, some users will be on this browser forever. All this suggests we would like to factor it out, in the name of the single responsibility principle and don't repeat yourself. And the extracted component should then be thoroughly tested to it's own why. That component's why, in particular, is to work around the browser bug, so a test specification that describes precisely which versions of Windows and IE are required to be worked around is actually exactly what you want. As to good robot control and screen geometry, I don't think that's really science fiction anymore, unless your requirements are more exacting than mine.

2 ms·

It's not always possible (or even advisable) to document with a test; to take two trivial examples from recent memory, one was a wrapping bug in IE 11 and the o

by javajosh 8y ago

couchand 8y ago
Your second example is a great example of how sometimes it's just not worth it. You're probably right that it makes sense to just write a comment and move along (after you've replicated the bug and filed an issue against the TypeScript compiler). Eventually it will get fixed, your team will upgrade their system, and you can remove the workaround. I'd argue the first example illustrates my point quite well (but forgive me if this gets too ivory tower). It would seem highly unlikely that the wrapping bug is intimately coupled with whatever else the component is doing. It will likely come up again in some other situation, in this project or another. After all, some users will be on this browser forever. All this suggests we would like to factor it out, in the name of the single responsibility principle and don't repeat yourself. And the extracted component should then be thoroughly tested to it's own why. That component's why, in particular, is to work around the browser bug, so a test specification that describes precisely which versions of Windows and IE are required to be worked around is actually exactly what you want. As to good robot control and screen geometry, I don't think that's really science fiction anymore, unless your requirements are more exacting than mine.