Earlier quoted context omitted.
Do testing frameworks normally catch memory leaks?
Mine do.
Which framework do you use?
The Servers Are Burning
51–60 of 158 posts
Re: The Servers Are Burning
#52Earlier quoted context omitted.
Mine do.
You can't possibly say that with any confidence. I literally just finished reproducing a memory leak caused by an insane combination of circumstances. This was not something valgrind or any similar tool would find. It was not something that any rational human being would have thought to write tests for. Once code is no longer synchronous, and tasks are being juggled around and swapped between, it becomes virtually im…
The parent is saying that their tests normally catch memory leaks, not that their tests catch all memory leaks.
Re: The Servers Are Burning
#53When 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 ment…
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.
Re: The Servers Are Burning
#54Wow. 1. We don't test. 2. We don't code review (or rather if we do, we do it so poorly swallowed exceptions don't raise red flags.) That's an outrageously unprofessional software process.
> That's an outrageously unprofessional software process.
People who call me unprofessional forget that being a professional just means I'm paid to do it, it's not a pass time.
Re: The Servers Are Burning
#55(then-CEO Mike Maxim) thought of testing frameworks as somewhat academic, more lofty than practical. ... Mike the CEO, who was also OkCupid’s best engineer... Mystery of the Melting Servers, solved.
Do testing frameworks normally catch memory leaks?
If you look at this quote one the article:
“That same story happened so many different times,” my old boss David told me. “Someone launched a small, relatively innocuous change that did one of the millions of unexpected things it could have done, which then happened to break some part of the site, and then bring it all down—sometimes bring it down to the point where we couldn’t recover it for hours.”
That’s exactly the problem that thorough automated test suites try to solve. When you have a robust mix of unit, integration, end-to-end and performance tests, you can greatly reduce the number of unintended regressions that make it into production. Not eliminate them completely, but definitely reduce them a tonne.
Re: The Servers Are Burning
#56Earlier quoted context omitted.
Mine do.
You can't possibly say that with any confidence. I literally just finished reproducing a memory leak caused by an insane combination of circumstances. This was not something valgrind or any similar tool would find. It was not something that any rational human being would have thought to write tests for. Once code is no longer synchronous, and tasks are being juggled around and swapped between, it becomes virtually im…
What's an example of a memory leak that can't be found by valgrind?
Re: The Servers Are Burning
#57Earlier quoted context omitted.
Mine do.
You can't possibly say that with any confidence. I literally just finished reproducing a memory leak caused by an insane combination of circumstances. This was not something valgrind or any similar tool would find. It was not something that any rational human being would have thought to write tests for. Once code is no longer synchronous, and tasks are being juggled around and swapped between, it becomes virtually im…
Tests only catch what you test for. In this case "memory leak" can be replaced with "site functions as expected", and the same argument you made applies, and yet it's still useful.
Just because you can't determine the exact cause of the leak, or even detect all of them, doesn't mean that having some indication of memory usage initially and under test loads of different (reproducible) amounts at different intervals and comparing them across builds can't get you a hell of a lot of utility.
Re: The Servers Are Burning
#58Wow. 1. We don't test. 2. We don't code review (or rather if we do, we do it so poorly swallowed exceptions don't raise red flags.) That's an outrageously unprofessional software process.
You have to judge it in context. If it's entirely a senior team then the value of code reviews is greatly diminished. You rarely catch a bug in a bug review when you're reviewing a Senior software engineer's code. those bugs aren't caught until you do testing.
Re: The Servers Are Burning
#59When 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 ment…
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 e…
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.
Re: The Servers Are Burning
#60When 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 ment…
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
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.