Live data from Hacker News

Poll: Do you test your code?

news.ycombinator.com

91–100 of 351 posts

Re: Poll: Do you test your code?

#91
post #79

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…

"Writing tests makes you think". A developer should already be thinking about these things when they are writing their code.

Sure, but context shapes behavior. People should be eating better too, but that's a lot easier to do when you have a fridge full of vegetables than a cupboard full of Doritos. Test-driven development forces me to think about code from the outside first.

Re: Poll: Do you test your code?

#92
post #64

I work in science. We agree that testing would be beneficial, but nobody codes well enough to actually get it done. To all language designers, there is a HUGE space for a better scientific language. Make it easy for Matlab users to understand, but include better encapsulation and library support. Tie in testing and proving from the core.

What about NumPy + unittest + all other Python libraries?

Re: Poll: Do you test your code?

#93

Earlier quoted context omitted.

I cannot supply individual test cases for everything that could possibly be found in the source data. Perhaps not, but you can supply test cases for known problems you might encounter, as well as ones you've solved after they've been encountered.

Yes, that's what I'm doing, but I feel it's a drop in the bucket.

It is, but as bug crop up you can add tests to ensure they don't crop up again. While it's not possible to ensure perfection, it does help ensure you don't 'revert back' to past problems.

Re: Poll: Do you test your code?

#94
I write tests today to make sure it works tomorrow. As projects progress, inevitably no matter what kind of ninja coder you are, a requirement that is beyond what you could have imagined will pop up. You can either say, no we can't do that... loosing a competitive advantage. Or you can can code without fear. Because when you're done, you have a full suite of sanity tests waiting to make sure you didn't mess things up. Unit tests can make an average guy like myself appear to be that Ninja coder those job ads are always asking for, the guy with the oakley glasses.

Re: Poll: Do you test your code?

#95
I do the testcases based on where the project is at that point in time. Here are the three stages, that can help you decide how much tests needs to be there.

[1] Initial stage where we are trying to make things work. At this stage code base is very small [2] Heavy development phase. At this stage, we have proved the concept. Now we are adding a lot of new features. We identified some features as must have. Also, code is getting re-factored/re-designed based on what we learn. At this stage, we add tests for the must have functionality. Thus, we can ensure that important features are not broken by newer code.

[3] Mature phase. The code is mature. Most of the features are working fine. Code base may be large 100000+ lines. At this stage re-factoring/re-designing is not easy. Mostly incremental changes are happening. At this point, we should have upwards of 70% code coverage. Typically, the test code will be more than the code when we have 70%+ code coverage. But, it is very important to have tests, since it ensures that all features are tested even when a minor code change is made.

Re: Poll: Do you test your code?

#96
post #6

Never forget you write software, not tests. Tests are here to increase quality, they have no raison d'être by themselves.

I suppose, but what is the value of untested code? This sounds like an excuse for coding without testing.

There are many ways to improve code quality. Using an automated test suite is only one of them, and while it's one that is widely useful, it is of very limited value in some circumstances and I think for some developers it instils a false sense of security. Not having an automated test suite that covers a particular part of your code does not imply that the code is "untested" or of no value. It just means some other approach is needed in that case.

Re: Poll: Do you test your code?

#97
post #81

I don't have a problem with the idea of test, as such, but I couldn't use them since I write webapps and what gives us issues isn't the Javascript code (about 80%) of the time. It is the CSS, or failing that, the interaction between Javascript and CSS, which I haven't seen any way to test automatically (such test would be able to answer 'given this code, does the resulting DOM look like picture $N'). Usually when the…

Jasmine is a behavior-driven development framework for testing your JavaScript code. http://pivotal.github.com/jasmine/

Re: Poll: Do you test your code?

#98
post #70
post #66

Earlier quoted context omitted.

If you mean that unit tests have accumulated a lot of dogma over the past few years, and you are saying they are "overrated" because you still need to think about how, what, and why you are testing, I agree. If you are using your post as an excuse for not using automated testing at all, I completely disagree. That's the bad kind of developer laziness. On the other hand, I do have to concede that when competing agains…

How much of that complexity is self-inflicted? Most of the unit testing advocates I know are also the worst architecture astronauts. Every line in a codebase has a cost, including tests. I'd rather deal with a code base that's as trim as possible. I've done unit tests before, but I don't find that they help that much, because they don't solve the most common source of actual production issues: things you didn't think…

I find they do help there. Having unit tests makes me trust my code better. Confronted with a "it does not behave as I would expect" issue, that trust helps me focus attention away from the implementation of those functions.

Problem with that is that, to get that trust, I need to know that unit tests exist, and, preferably have spent time writing or reading them. Question then is whether that time would not be spent better on reading the existing code. I think that, often, the answer to that is "no", but I cannot really argue that.

Perhaps, it is because writing unit tests puts you explicitly in "break this code (that may not have been written) mode". Writing a unit test that calls a function with some invalid arguments and verifies that it throws is often simpler than reading the code to verify that. Also, unit tests may help in the presence of bug foxes and/or changing requirements. Bug report/Requirements change => code change => unit tests break => free reminder "oops, if we change that, feature X will break".

Re: Poll: Do you test your code?

#99
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…

There's a lot of truth to this. I work in a project with a lot of separate assemblies, because we have many applications that share similar functionality. Unit tests are critical to making sure I don't break something for one application while making a change for another. However at the same time, It can be a real pain to load the entire application to test it. Unit tests have actually increased my productivity in some areas where doing a test has about a 1-5 minute overhead (compiling than loading a file etc)

Re: Poll: Do you test your code?

#100
post #15

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'm doing a startup as well, and we do a fair bit of testing.

One of the keys to making that work for us is a short feedback loop. We automatically release on every commit, which means every couple of hours. Speculative features get minimally implemented; if they look good then we beef them up more. Our goal is to avoid not just the unneeded tests, but the unneeded feature code too.

I'm personally pretty happy with the testing in that we don't have to spend much time on debugging or manual testing. It's very nice to make a major change, poke at it a little bit, and then ship it with a fair bit of confidence that it will work.

Post reply on HN