Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I was thinking, is there a particular time in your coding where you verify that it works? Say, after coding a function, or an entire class, or an entire section of an app, or after every 'significant' block of code?

I ask this, because I tend to verify my app too often, sometimes after every 3rd or 4th change. This is a habit which has proven very hard to shake. It appears to be counter productive to do this repeatedly and manually.

Is there another solution? It seems to be either be a more competent programmer and essentially 'know' the return of the majority of your code, or have your IDE check the return periodically, or only test the return via TDD.

share|improve this question
3  
You might want to rephrase this in such as way that it can more easily have a single, objective answer. As it is, this seems to be asking for people to post a list of stuff, and that will probably lead to this question getting closed. –  FrustratedWithFormsDesigner Apr 24 '12 at 17:25
    
I'm not fishing for a mountain of answers, if that is what you mean. I want relevant, targeted answers from a few people who have been in this position. If they also have other such habits they found hard to shake, then I'd be interested to hear them, that is all. I'll rephrase the title.. –  Damien Roche Apr 24 '12 at 17:28
5  
Check the return? I'm not sure what that means. If you mean the return value of a function... unit tests can do that on every compile or at the click of the mouse. –  Steve Evers Apr 24 '12 at 17:30
1  
@Zenph Moderators did not close this, the community decided to close this question. If you wish to dispute this then please ask a question on Meta. –  maple_shaft Apr 24 '12 at 18:10
1  
@Zenph I edited your question to clarify what you are asking. I think this helps it fit better within the goals of the site. Hopefully, that will gain a couple more reopen votes, because there are good answers available for the newly updated question. –  Mike Brown Apr 24 '12 at 19:51
show 5 more comments

4 Answers

up vote 7 down vote accepted

Sounds like you're spending too much time manually testing your application and should try automating this process with tests.

or have your IDE check the return periodically

There isn't a real way to do this other than to write your own tests with self-written assertions.

If shipping broken code is killer to your business and your application has complexity (which it sounds like it does) you should be writing tests to verify behavior.

Tests aren't a silver bullet but will make maintaining existing work a lot easier.

or only test the return via TDD.

It should be noted that you don't have to be doing TDD to have automated tests.

share|improve this answer
    
Thanks. Question was closed as not constructive even though your answer helped me (and most probably others in a similar situation). Thanks for your time. –  Damien Roche Apr 24 '12 at 17:39
    
I'm glad to see the question was re-opened! What's wrong with someone coming upon the same conclusion others have in the past? If you absolutely can't afford to regress on features and want to speed up maintenance, unit testing is the logical conclusion. It's quite interesting to read the struggles of someone who makes a case for unit testing before knowing what it is. –  brian Apr 25 '12 at 0:16
add comment
  • Problem is that you don't have any confidence in your code. Yes, partially it's a "bad habit", but I think the main problem is indeed a lack of confidence.

  • Eventually you'll be working on a system where you won't be able to verify your change instantly. This is likely to have a negative impact on your productivity.

  • To address this you need to set yourself a target and increase that target gradually.

  • Unit tests will help you when testing individual components, but there is only so much that can be done with unit tests. This becomes more relevant in enterprise systems.

  • Each time you break something, or the system does something you didn't expect it to, make a note of what happened and how you fixed it. Eventually you should start seeing a pattern. You should be then able to address this by evaluating your stats.

  • I'm also assuming that you have been a developer for a relatively short period of time, so the confidence in your code will grow with your experience.

share|improve this answer
add comment

Create unit tests. If you're into the test-first thing, you write the test first and check the return as soon as you write the method. If you're not, you should write the unit test as soon as possible after you write the method.

Either way, you should test your code before you move on.

share|improve this answer
add comment

Create unit-tests and automate your testing but also stop testing so often. Take an extra minute to re-read what you've written and increase your confidence that it works. That way you don't rely on unit-tests to catch the simplest mistakes and you increase confidence in your own ability.

Anecdote: I was tutoring a student and they wanted to compile the code and test it after changing a few lines, I told them no and we proceeded to write out all the code that we needed and then tested it. Before testing, we went through line by line to make sure the logic was correct. In the end, the compiler only caught misspellings and the unit-tests caught no errors.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.