5 ms·

Maybe you can help me understand this. Since you don't write as many tests, that means you're not actually testing all your code branches because tests incur t

Maybe you can help me understand this. Since you don't write as many tests, that means you're not actually testing all your code branches because tests incur technical debt after all. So does this mean you test every single branch manually? just don't bother with it at all? Do you just have a few integration tests and they break and you spend a good chunk of time figuring out which logical branch broke? What happens if you make a typo, comment out a piece of code and forget to uncomment , etc? I'd love to write less tests but don't know how to do it?

LanceH 7y ago
I write tests when I know the answers before to some complicated code. A good example of this is writing some code to tell if a point is inside a triangle or not. Setting up the test case is easy with three points for the triangle, a point or two inside, points outside, etc... Writing the code is simple enough, but possibly prone to flipping a sign for a slope, or maybe translating the equation wrong. If I'm writing a web app, I just don't bother to write them before hand. I mostly code until I get what I want and then write the test. I think of this as "nailing it in place". I want to make sure through the test that this code continues to produce what I expect. I'll write as many tests as I feel are necessary but probably not explore every branch.
sdenton4 7y ago
Yeah, as soon as code has more than two "real" branches, I don't trust myself to manually test them all. One of them will be broken quickly if I keep hacking in a particular branch. (This is, secretly, also an argument for writing code in sufficient generality to avoid this phenomenon in the first place.) I also never trust a test that passes the first time I run it. I am both terrible at writing correct code, and completely normal in that regard.
- allannienhuis 7y ago
  I believe he's using the term branch different than you : 'alternate code path'
  - sdenton4 7y ago
    No, alternate code path is exactly what I mean. What's the functionality I'm coding in support for today, in addition to the stuff I was supporting yesterday? How do I know the stuff from yesterday still works? TESTS!
_-o-_ 7y ago
Most of the typoos and obvious errors are caught by IDE thanks to intelligent code completion systems and linters. If you're writing in a compiled language - compile step might catch some of the more obvious errors too. I manually test my current branch manually while developing and do sanity checks when it's merged somewhere. I do write tests for some cases, but rarely, only to save time when I have to test against a wide range of input parameters.
ggregoire 7y ago
> What happens if you make a typo, comment out a piece of code and forget to uncomment , etc? Thanks god this is handled out of the box by any compiled language. I can't imagine myself writing tests to catch non-logical bugs.

LanceH 7y ago

I write tests when I know the answers before to some complicated code. A good example of this is writing some code to tell if a point is inside a triangle or not. Setting up the test case is easy with three points for the triangle, a point or two inside, points outside, etc... Writing the code is simple enough, but possibly prone to flipping a sign for a slope, or maybe translating the equation wrong. If I'm writing a web app, I just don't bother to write them before hand. I mostly code until I get what I want and then write the test. I think of this as "nailing it in place". I want to make sure through the test that this code continues to produce what I expect. I'll write as many tests as I feel are necessary but probably not explore every branch.

sdenton4 7y ago

Yeah, as soon as code has more than two "real" branches, I don't trust myself to manually test them all. One of them will be broken quickly if I keep hacking in a particular branch. (This is, secretly, also an argument for writing code in sufficient generality to avoid this phenomenon in the first place.) I also never trust a test that passes the first time I run it. I am both terrible at writing correct code, and completely normal in that regard.

allannienhuis 7y ago
I believe he's using the term branch different than you : 'alternate code path'
- sdenton4 7y ago
  No, alternate code path is exactly what I mean. What's the functionality I'm coding in support for today, in addition to the stuff I was supporting yesterday? How do I know the stuff from yesterday still works? TESTS!

_-o-_ 7y ago

Most of the typoos and obvious errors are caught by IDE thanks to intelligent code completion systems and linters. If you're writing in a compiled language - compile step might catch some of the more obvious errors too. I manually test my current branch manually while developing and do sanity checks when it's merged somewhere. I do write tests for some cases, but rarely, only to save time when I have to test against a wide range of input parameters.

ggregoire 7y ago

> What happens if you make a typo, comment out a piece of code and forget to uncomment , etc? Thanks god this is handled out of the box by any compiled language. I can't imagine myself writing tests to catch non-logical bugs.