4 ms·

When making something new where you're not sure of the value yet, I've found that you can get 80% of the benefits of unit tests with around 20% of the tests you

by matt2000 8y ago

When making something new where you're not sure of the value yet, I've found that you can get 80% of the benefits of unit tests with around 20% of the tests you'd write to get "full coverage." My main goal is to at least have the code run in an expected way and produce an expected result. This doesn't catch everything, but it does seem to catch enough problems to be worth it for the time invested. Edit: I should mention that I also add tests to cover something when I experience a failure, so it at least won't happen again.

sneak 8y ago
Yes to the last! Whenever bughunting my first step is to reproduce the issue in a failing test. This has the benefit of me being sure I know what is failing and how, but also crystallizes then knowledge and experience into the repo for future engineers (or future me) to know the most common/practical ways things break in the real world. It is also marginally useful for catching regressions, if the test is clever/general enough.
ddebernardy 8y ago
The big problem I've noticed when reading unit tests in various projects is that they frequently test the implementation rather than the outcome: https://softwareengineering.stackexchange.com/a/304910/24932 https://softwareengineering.stackexchange.com/a/304910/24932
- macintux 8y ago
  That's one reason I really like functional programming: it's easier to test pure functions, vs code with side effects that requires you to look at the internal state afterwards.
  - tobr 8y ago
    On the other hand, pure functions are also much easier to reason about, thus much less likely to cause bugs from "a tiny change" in the first place. It's in the messy imperative stuff things tend to break in incomprehensible ways, and where you really need tests.
- matt2000 8y ago
  I still find there's a fair amount of value in just having most of the code be executed regularly (on every commit, for example), even if you're not perfectly testing the output.
jerkstate 8y ago
I'm not a great programmer, I can't usually write code that does exactly what I expect the first time, so I use unit tests with a debugger in my IDE to run small portions of my new code until it works the way I envisioned it before I started writing it. This is a lot faster than my old method of writing code that doesn't quite work, and running the whole program over and over with small changes and print statements each time.
- matt2000 8y ago
  Yes, that's pretty much where I've gotten to as well. Might as well put in the effort to move that process into unit tests as then you get to run it repeatedly for free from then on.
- TeMPOraL 8y ago
  > so I use unit tests with a debugger in my IDE to run small portions of my new code until it works the way I envisioned it before I started writing it. In languages like Lisp, this is what you use REPL for. It's an insanely more efficient way of working than the usual edit->recompile->run the whole app again. However, couple of years working with Common Lisp and (recently) Clojure taught me that, even with a good REPL at your disposal, properly testing code as you write it can get pretty unwieldy - especially if the inputs are complex/large. I found it beneficial to write unit tests and call them from REPL instead of testing the code in REPL directly, as it's easier to maintain and develop individual test cases, as well as re-test all of them when I alter the code I'm working on. (That's of course apart from the fact that unit tests are more permanent, and provide value later on.) TL;DR: thumbs up for writing unit tests even when working in an interactive programming environment.
  - nradov 8y ago
    Even with Java now it's usually possible to modify a running application while you're debugging. Eclipse handles this pretty well.
  - Sophistifunk 8y ago
    REPLs are a great tool for exploring your ideas, and poking your software to test it "right now" but once you're happy with a small piece of code, nothing beats a suite of unit tests to help you refactor with confidence as your implementation gets a bit too hairy and you need to rejigger it in order to progress in a direction you didn't see coming.

sneak 8y ago

Yes to the last! Whenever bughunting my first step is to reproduce the issue in a failing test. This has the benefit of me being sure I know what is failing and how, but also crystallizes then knowledge and experience into the repo for future engineers (or future me) to know the most common/practical ways things break in the real world. It is also marginally useful for catching regressions, if the test is clever/general enough.

ddebernardy 8y ago

The big problem I've noticed when reading unit tests in various projects is that they frequently test the implementation rather than the outcome: https://softwareengineering.stackexchange.com/a/304910/24932 https://softwareengineering.stackexchange.com/a/304910/24932

macintux 8y ago
That's one reason I really like functional programming: it's easier to test pure functions, vs code with side effects that requires you to look at the internal state afterwards.
- tobr 8y ago
  On the other hand, pure functions are also much easier to reason about, thus much less likely to cause bugs from "a tiny change" in the first place. It's in the messy imperative stuff things tend to break in incomprehensible ways, and where you really need tests.
matt2000 8y ago
I still find there's a fair amount of value in just having most of the code be executed regularly (on every commit, for example), even if you're not perfectly testing the output.

jerkstate 8y ago

I'm not a great programmer, I can't usually write code that does exactly what I expect the first time, so I use unit tests with a debugger in my IDE to run small portions of my new code until it works the way I envisioned it before I started writing it. This is a lot faster than my old method of writing code that doesn't quite work, and running the whole program over and over with small changes and print statements each time.

matt2000 8y ago
Yes, that's pretty much where I've gotten to as well. Might as well put in the effort to move that process into unit tests as then you get to run it repeatedly for free from then on.
TeMPOraL 8y ago
> so I use unit tests with a debugger in my IDE to run small portions of my new code until it works the way I envisioned it before I started writing it. In languages like Lisp, this is what you use REPL for. It's an insanely more efficient way of working than the usual edit->recompile->run the whole app again. However, couple of years working with Common Lisp and (recently) Clojure taught me that, even with a good REPL at your disposal, properly testing code as you write it can get pretty unwieldy - especially if the inputs are complex/large. I found it beneficial to write unit tests and call them from REPL instead of testing the code in REPL directly, as it's easier to maintain and develop individual test cases, as well as re-test all of them when I alter the code I'm working on. (That's of course apart from the fact that unit tests are more permanent, and provide value later on.) TL;DR: thumbs up for writing unit tests even when working in an interactive programming environment.
- nradov 8y ago
  Even with Java now it's usually possible to modify a running application while you're debugging. Eclipse handles this pretty well.
- Sophistifunk 8y ago
  REPLs are a great tool for exploring your ideas, and poking your software to test it "right now" but once you're happy with a small piece of code, nothing beats a suite of unit tests to help you refactor with confidence as your implementation gets a bit too hairy and you need to rejigger it in order to progress in a direction you didn't see coming.