71–80 of 351 posts
I used to get code back from developers EACH AND EVERY TIME with massive bugs like: unable to register, unable to login, unable to add content. I wrongly assumed that they at least ran through and checked for any bugs they introduced before sending me the new code. So each and every time I got code back I had to go through manually and check it, sign in, log out, register, add content, delete content, edit content, a…
Earlier quoted context omitted.
The very first thing I do when I take over a codebase is to write tests. Without tests, it's impossible to do maintenance work or add functionality in any sort of rigorous fashion--how can you know that your assumptions about how the code works are correct? How can you know that your trivial change didn't break something? Of course, tests don't actually tell you these things. But they can tell you that your assumptio…
Do you always have the time/bandwidth to write these tests? I'm curious what you might do if an old codebase lands in your lap and someone says "here, fix these bugs by the impossible_length_of_time." I appreciate the idea here, and I've done the same in certain circumstances, but typically that means writing tests for bits of functionality that I need to touch.
Without good automated, easy-to-run tests, you're going to blow more time fixing bugs and ad hoc testing in the long run.
Thinking you save time by not testing is a lie on all but the most trivial of projects.
We have a test framework and a devoted team of people dedicated to encouraging the use of said framework but the rest of our engineering staff don't get it.
I don't believe anybody that says they test all functionality. Most? Sure. All? No way. Not in a non-trivial codebase. Article about the group that writes the space shuttle software, sort of relevant?: http://www.fastcompany.com/magazine/06/writestuff.html
However, if you consider functions on the code level (e.g. Java methods) then organisations with 100% coverage will be thin on the ground. If you go further and consider line coverage, almost nobody will have 100% coverage.
A common problem with organisations claiming to test all functions is that they will only test the happy path - there will be few tests for things like unexpected or illegal input etc.
Earlier quoted context omitted.
Well, there's `all` and there's virtually all. All is 100% branch and statement coverage, and is a big waste of time. When I saw my codebase has 'all' functionality tested, I mean we don't commit code without tests included too. I think that's a pretty reasonable definition.
100% branch and statement coverage doesn't begin to cover "all". Consider: double sin(double x) { return x; } Simply testing x = 0 gives you 100% branch and statement coverage, but I don't think you want to ship just yet =)
However, even if the sin function is already tested elsewhere, you will still need further testing to ensure that you are calling it correctly (e.g. not confusing degrees and radians).
EDIT: Yes, I read it wrong - clearly need coffee...
Earlier quoted context omitted.
what what are you even saying i dont even ( More concretely, if you use testing to drive your refactors and architecture--as opposed to, say, finding pain points in normal code or actual design time in preproduction--I would be concerned that you are "guardrail programming", as a gentleman put in a talk I saw recently. When we drive, we don't have guardrails to bounce us back on the road every time we veer off--they'…
I disagree completely, and your comment makes me think you've never seriously used unit testing. Writing tests makes you think about how pieces of your code interact with each other, dependencies etc. As an example, if you're trying to test Function A and are finding you need tens of lines of setup code to be able to do so, then that would be a warning sign that you may want to think about refactoring out some of tho…
I certainly support unit testing, as its essential--and anyone telling you otherwise is bonkers--to ensuring that code follows contract.
That said, if unit testing was great for design but didn't spot errors, it'd be useless. Whereas, if it was useless for design and good for errors, that's okay, because I can do the design work myself.
Earlier quoted context omitted.
what what are you even saying i dont even ( More concretely, if you use testing to drive your refactors and architecture--as opposed to, say, finding pain points in normal code or actual design time in preproduction--I would be concerned that you are "guardrail programming", as a gentleman put in a talk I saw recently. When we drive, we don't have guardrails to bounce us back on the road every time we veer off--they'…
I disagree completely, and your comment makes me think you've never seriously used unit testing. Writing tests makes you think about how pieces of your code interact with each other, dependencies etc. As an example, if you're trying to test Function A and are finding you need tens of lines of setup code to be able to do so, then that would be a warning sign that you may want to think about refactoring out some of tho…