Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Poll: Do you test your code?

news.ycombinator.com

Post reply on HN
Print view View original

131–140 of 351 posts

Re: Poll: Do you test your code?

#131

Post by falcolas »

stephencanon wrote: post #25
falcolas wrote: post #23

Earlier quoted context omitted.

I'm a lot less surprised. Not everyone gets to work on a shiny new codebase which was created after regular testing was the norm. A lot of us work on maintaining code that's 5/10/20 years old, and have to worry about things like maintaining and adding functionality over refactoring the entire codebase to support unit tests. When you're in this position, your going to get more value out of creating a smaller set of fu…

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…

Of course working on a code base without a majority test coverage is dodgy (and intellectually frustrating), but it's a necessary skill.

I feel that it is unreasonable to expect that you will be able to pick up any code base and immediately write sufficient tests to get coverage on a majority of the code base. Speaking from my experience picking up old code bases, just being able to write isolated unit tests would require refactoring most of the code base, which is typically not something you will have time to do before you're expected to do other work.

I can't think of a single manager that I've worked for who would accept me saying, "it's going to take me 3-6 months of refactoring & building tests before I can start fixing bugs and providing enhancements."

Re: Poll: Do you test your code?

#132

Post by [deleted] »

amouat wrote: post #77
stephencanon wrote: post #56

Earlier quoted context omitted.

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 =)

That's not entirely fair - you haven't tested the branches or statements inside the sin function. 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...

[deleted]

Re: Poll: Do you test your code?

#133

Post by joefiorini »

obiefernandez wrote: post #68

These options are flawed. I am somewhere in the middle of of the first two: mostly integration tests, with critical domain logic unit tested. Certainly not 100% of the app's functionality, closer to 80%

I'm had the same thought Obie. I find high level integration tests provide most of the value for me, with unit testing when I need help with designing code. Having a decent suite of high level tests saves me from having to smoke test the entire app every time I make sweeping changes. If the suite is passing, I know the features are working, at least in the basic cases I was testing for. I still have to do some level of manual testing, but it's nowhere near as much as I did before I became more obsessed with testing.

Re: Poll: Do you test your code?

#134

Post by MartinCron »

bmj wrote: post #30
stephencanon wrote: post #25

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.

Do you always have the time/bandwidth to write these tests?

Does an ER surgeon always have the time/bandwidth to scrub hands before surgery?

Re: Poll: Do you test your code?

#135

Post by bguthrie »

mtrimpe wrote: post #15
peteretep wrote: post #7

People ... don't have tests? o_O In 2012? I am seriously considering putting together a "Software Engineering for Small Teams" course or set of articles. With a little bit of expertise, you can inject testing in to most projects, use the minimum of Agile that'll help, and generally massively raise your game - and by that I mean code faster, better, and more reliably, with considerably less stress. (edited: turns out…

I think it all depends. I used to always write proper full-fledged tests. Then I started my startup, building a product in the few hours left after a demanding high-stress job and a tumultuous private life. Within a few weeks, I stopped writing tests. Within a few more weeks, I turned off the test suite. I wrote the product, got it working, received market feedback, realized my model was all wrong, rewrote the entire…

I'd been working for years in a workplace that tests virtually everything up front until I joined a startup, and I agree with you.

Experimental features may be very short-lived, or require extensive tweaks, and the technical debt that accumulates from not testing may never arise over their lifetime. Once you're sure it's going to stick around forever, do it right and cover it with tests.

Re: Poll: Do you test your code?

#136

Post by MartinCron »

d-roo wrote: post #82

I was in the 'testing is too much overhead' crowd for years until one day I finally got it. I realized that as I code, I'm always testing. Who doesn't make a change and then test it? So, you consider writing a test too much overhead? How much overhead is it to manually test? How much overhead is it to fill out that registration form you're testing? Maybe there are two or three steps to it. How much time does that tak…

True story: I took over for a developer working on a large and complex multi-step form. I wasn't surprised that there were a few little bugs in it, but I noticed that the number and severity of the bugs increased as you went through the form. The first step was pretty much bug free, but the final step was completely broken.

Many people who claim that test automation is "too much overhead" either don't understand what test automation is or don't understand what overhead is. If you have to test everything in order to change anything you either have a huge manual testing overhead or have a huge quality liability.

Re: Poll: Do you test your code?

#137

Post by hrktb »

TylerE wrote: post #62
tomgallard wrote: post #55

Earlier quoted context omitted.

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've seen code in productions apps with comments along the lines of "this isn't optimal, but it's easier to test". Every time I do, I die a little inside. Unit tests are THE most overrated buzzword of the last 10 years.

Aside from the unit tests pb, suboptimal but easy to test code is critical in a lot of situations, like time critical bug fixes or last minute feature addition on a production site.

Most of the time, testing takes more time than writing the code, so throwing optimality under the bus can be the best choice. If it's Good Enough nobody's going to rewrite, but I wouldn't see it as something inherently negative or shameful, it's just a question of priorities.

Re: Poll: Do you test your code?

#138

Post by MartinCron »

hndl wrote: post #45

Another interesting question: how often do your tests run? Most folks probably run unit tests with continuous integration but what about functional and performance driven tests?

Most tests (unit, integration, etc.) are triggered when new code is checked in. For other kinds of tests, we use schedule triggers to run them at a particular cadence, either overnight or more frequently if that's what needed.

TeamCity is good for automating with both kinds of "triggers".

Re: Poll: Do you test your code?

#139

Post by rhizome »

trustfundbaby wrote: post #120

I've never done automated testing, but as I've grown as a developer and started dealing with more complicated codebases, I have come to see the importance of testing in a huge way. With a small codebase that you know every inch of, its easy to test most of your interactions before you push something live, but when you get just one order of magnitude higher you start seeing how easy it is to write code in one section…

Trapping regressions is a HUGE driver for testing for me.
Post reply on HN