341–350 of 351 posts
When you are writing any code, you should try to predict if what you will gain out of it will be worth it. In other words: evaluate the risks of anything you do in your life.
Bottom line is: test code is code and you have to maintain it. If you write code that does not give you anything in return, or gives you more headaches than anything else, you wasted your time when you wrote it. When you are writing any code, you should try to predict if what you will gain out of it will be worth it. In other words: evaluate the risks of anything you do in your life.
Why is there no "and also click" option for, "we are unhappy with the amount of testing we do, and are gradually adding more".
Really, downvoted? The survey seems predisposed to result in the conclusion that testing is a waste of time. My company finds it worthwhile enough that we are never happy with what we have. We could always write better tests, but we need more engineers than we can find to hire. So we are unhappy with the current situation, but are working to improve.
Earlier quoted context omitted.
New hacker news rule: if you haven't done at least 80% of what he's talking about, you can't dick-measuring-contest him. From scratch work is the easier part of programming.
I've done this before, friend. Starting from scratch is indeed easier. The point I was making was that he used unit tests to confirm his design (as a safety net) and not as a primary design tool.
Earlier quoted context omitted.
Then you didn't write good enough tests. I have deployed code that thousands of customers see without manually testing it. If my tests are green, I'm confident in deploying my code.
What tests your tests?
Earlier quoted context omitted.
Different levels of tests work here. I usually start with a very high-level test and then as I implement I do unit tests once I have a reasonably high confidence that the units are a good design. You should often be able to at least create an automated acceptance test for what you're doing (e.g., "as a user I want to click this button and see XYZ"). This is usually extremely decoupled from the implementation so it sh…
"If that doesn't seem doable you might be taking on a task that doesn't have a good set of requirements." Or it might have perfectly good requirements which are very hard to write automated tests for. Consider (for instance) a program to translate ABC music format to proper sheet music. It's easy to say the basic requirement: "The program has to accurately translate ABC format to legible and easy to read sheet music.…
Earlier quoted context omitted.
I have never seen any half way decent developer write code for more then a few minutes without some sort of feedback, automated test suite or not. You are right that it will work more or less, but they work out the "less" part of that statement sooner rather then later. In my experience, that is a place you get to over time, only the people out of college write code for multiple hours straight, then debug everything…
> I have never seen any half way decent developer write code for more then a few minutes without some sort of feedback, automated test suite or not I do this all the time. Two reasons: 1. I can keep in "the flow" for an extended period of time. This is more important if the code is especially complicated. If I have to stop every few minutes to fix trivial errors, it's easy to forget important details of how everythin…
Not all of us have 10 years to work on everything. ;)
Earlier quoted context omitted.
Please don't fix this with a technical solution. There is some reason that your developers aren't engaged in the work. Figure out why they don't care about working code or the user experience and fix that. If you plug the obvious holes, you won't have fixed your quality problems; you'll just shift them to the places where you won't notice them right away.
Please don't fix this with a technical solution. I can't agree more with wpietri above. There surely is a non-technical problem at play. That isn't to say that you shouldn't try to automate your babysitting, but if your need for babysitting is that severe, you have other problems.
Earlier quoted context omitted.
The very first thing I do when I take over a codebase is to write tests. Without tests, it's impossible to do maintenance work or add functionality in any sort of rigorous fashion--how can you know that your assumptions about how the code works are correct? How can you know that your trivial change didn't break something? Of course, tests don't actually tell you these things. But they can tell you that your assumptio…
Of course working on a code base without a majority test coverage is dodgy (and intellectually frustrating), but it's a necessary skill. I feel that it is unreasonable to expect that you will be able to pick up any code base and immediately write sufficient tests to get coverage on a majority of the code base. Speaking from my experience picking up old code bases, just being able to write isolated unit tests would re…
I can't think of a single developer I've worked with who would try that approach.
When a bug is identified in a project with few-or-no tests, the approach that I usually see taken is to write some sort of large, slow integration test that exercises bug, then fix that. That allows you to prove that the bug exists and prove that the fix fixes it, at least for the documented case(s).
There's no reason to cover an entire legacy code base with tests if you're only changing a small portion of it.