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.
Poll: Do you test your code?
91–100 of 351 posts
Re: Poll: Do you test your code?
#92I 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.
Re: Poll: Do you test your code?
#93Earlier 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.
Re: Poll: Do you test your code?
#94Re: Poll: Do you test your code?
#95[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?
#96Never 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.
Re: Poll: Do you test your code?
#97I 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…
Re: Poll: Do you test your code?
#98Earlier 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…
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?
#99I 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…
Re: Poll: Do you test your code?
#100People ... 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…
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.