What is the alternative to frequent manual verification?

Question

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.

Answer 1

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.

Answer 2

• 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.

Answer 3

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.

Answer 4

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.