Every single line of code...
Poll: Do you test your code?
331–340 of 351 posts
Re: Poll: Do you test your code?
#332Earlier quoted context omitted.
Perhaps you need to read it a little more closely? For the given function, he has indeed tested all the branches and statements.
Also, it's the simplest thing that can possibly work! (And for very small values of x is also the best possible implementation.)
Even better: it's a correctly-rounded implementation for nearly half of the input space!
Re: Poll: Do you test your code?
#333Earlier quoted context omitted.
I'm pretty far into the extremist side of TDD, and I'll say that there is a thing as TOO many tests. Your test suite needs to run fast to be really useful. If you have thousands of full stack integration tests that takes an hour to run, you're not going to run them as often as you should be, if at all, ad might as well delete them.
If they are run by a continuous integration server on check in, it kind of doesn't matter how long they take to run.
Then they need to be moved to a different place, at least. Tell your CI server to use them, but more them out of the way for normal developers.
Re: Poll: Do you test your code?
#334Earlier quoted context omitted.
I'm working on a single page app that's about 30% Rails and 70% Coffeescript/Backbone.js. Test::Unit is practically useless for us since users never hit any plain HTML pages besides the login page. Imagine the current HTML5 Pandora having bugs with one particular song in Chrome only. How do you test for that using Test::Unit?
there are a bajillion libraries out there for unit testing javascript (something test::unit-ish would be qunit). rails + backbone + JST style templating actually makes TDDing your js relatively painless
We're looking into integration-level testing for our Javascript since it'd give us full coverage of the bugs we see.
I forgot to mention we also use Socket.io for real time push updates to user Backbone models. A good number of bugs don't crop up until another user modifies data and those changes get pushed out to another person.
Re: Poll: Do you test your code?
#335Earlier quoted context omitted.
I'm pretty far into the extremist side of TDD, and I'll say that there is a thing as TOO many tests. Your test suite needs to run fast to be really useful. If you have thousands of full stack integration tests that takes an hour to run, you're not going to run them as often as you should be, if at all, ad might as well delete them.
If they are run by a continuous integration server on check in, it kind of doesn't matter how long they take to run.
Completely false. You need to know that your change doesn't break the build, and if you wait a long time, you will have mentally switched gears when informed of the breakage. This is a big productivity sink.
(What's worse is when changes come in faster than the CI system can run the tests. Then you don't know which change broke your build because many changes were tested at once.)
Anything longer than 10 seconds is too long, in my opinion. As soon as you can get up to get coffee while your tests are running, you've lost a lot of productivity. (I recently finished a project where the tests took about ten minutes to run. That meant I could only change code 50 times per day. If the tests had taken 10 seconds, I would have been able to be make 300 changes per day. That's a 6x productivity increase right there.
Fast running test suites are absolutely essential.
Re: Poll: Do you test your code?
#336Testing is ideal for established business.
Testing is inefficient for some early stage startups which very often change the way their product works (features/ui).
Re: Poll: Do you test your code?
#337Earlier quoted context omitted.
But then you'd still do the manual test after you complete your code. Nobody (I hope) codes blind hoping it would work or caught later by a test suite. Test suits don't reveal everything. Only what you tested for.
Even if you test manually what you just changed, in a relatively complex codebase how can you guarantee that your changes haven't broken behaviour in a separate yet related aspect of the system? This is what I find the major advantage of a comprehensive test-suite to be, I don't have to worry as much about breaking any part of the system as a whole - if my suite passes, then I know everything I've worked on so far wo…
You can never actually guarantee anything even if you have tests.
The tests will only increase the likelihood of catching regressions.
Re: Poll: Do you test your code?
#338Earlier quoted context omitted.
Look at it this way: you must be testing code as you write it anyway. There's really no other sane way to do it. You make a change, you load the page and see that your change worked, or you call your new function from an interactive interpreter. Smart automated testing just takes all that extra test work you're already doing and saves it as you go along. No need to try to invent extra things to test. You just test wh…
Smart automated testing sounds amazing, until you realize that it's not smart at all. The dumb computer that you're ordering to do your bidding is the same dumb computer that is going to be running your tests, and chances are the programmer is invariant as well. In short, good programmers need unit tests less and bad programmers will write bad tests. You can't fix a personnel problem with technology.
[deleted]
Re: Poll: Do you test your code?
#339Earlier quoted context omitted.
Look at it this way: you must be testing code as you write it anyway. There's really no other sane way to do it. You make a change, you load the page and see that your change worked, or you call your new function from an interactive interpreter. Smart automated testing just takes all that extra test work you're already doing and saves it as you go along. No need to try to invent extra things to test. You just test wh…
Smart automated testing sounds amazing, until you realize that it's not smart at all. The dumb computer that you're ordering to do your bidding is the same dumb computer that is going to be running your tests, and chances are the programmer is invariant as well. In short, good programmers need unit tests less and bad programmers will write bad tests. You can't fix a personnel problem with technology.
Exactly. The computer will just repeat what you tell it to do. There is the chance that you will tell it wrong (a bug in your test code), and the chance that what you told it is not true anymore. An automated test basically saves you the work of doing the same thing over an over again as you develop.
But we must keep in mind that maintaining test code has a cost. Automated testing is not a holy grail and it isn't useful 100% of the time. You should carefully decide what code is worth testing via automation.
Unit tests in general don't catch any regressions, they only help you develop.
Functional tests might be useful, but only if you are testing something that is not likely to change much. E.g.: It is not worth to automate testing the UI if you are going to completely redesign it next month.
Manual testing can actually be cheaper than maintaining test code.
Re: Poll: Do you test your code?
#340We need to test more. I've run projects before that had over 1500 automated tests..mostly written by myself, it was beautiful and so simple to make invasive changes. We have a lot of catch up to do right now, but i think thats what "startups" often do. We will catch up with the tests in the next month or so, at the end of the day I know perfectly well that without them pivoting and making invasive changes will simply…
And how often did you have to rewrite those tests because you were drastically changing the architecture of your code?
Do you think the effort of maintaining all those tests might not have paid off? This question is very tricky to answer.