ShaunCodeweaver

Very much this - though I've experienced this in other stacks.

Would love to know the best way people handle this.

I totally agree, but even just the basics can be a great addition. What I find odd is even just simple things such as pre or post conditions don't appear to be used widely, let alone cool features built into languages such as Eiffel or D.

What lmm said is spot on.

If your paranoid about null pointers in C/C++, use asserts or static analysis.

"Anyway, this gets used lots of times by my algorithm"

You've got a missing class. The fact you're so concerned with testing it highlights this.

The fact it's private I should be free to rename, add or remove parameters. If I did this to your private method, I'd break unit tests, despite the code being private.

For the null reference problem, it depends on your language. But the point remains the same. For public API's, e.g something you let the outside world consume, checking for null etc.. will be required. For internal code, don't bother. Go as high as you can in the stack and fix the root cause of the null reference in the first place.

This article is wrong in numerous cases.

Testing private methods? Wrong. Don't do this. They'll be covered by your public API, if they aren't, delete them. If you need to test code that is private, you've got a missing abstraction. Pull that code out into a separate class, make the method public.

Testing you get a null reference when you send in null to a method? So what? You're testing Java/C#/etc... if you do this. Test for behaviour.

Need to use tear down methods? You're not unit testing anymore.

At least the article never recommended testing accessors... Again, please don't.

Care to expand givan?

Despite usually hating viewing slides without the presentation, I actually find this style very good for getting the point across.

Hammer down and there are some good quotes/ideas in there.

Exactly. Refactoring is the process of changing code without changing behaviour. If that means you change some tests so be it. There is no rule to say that you can't do this, but many devs seem to fear this.

That's right Colin. I completely agree, however if you break unit tests during a refactor, yet there is no functional change - bin the tests as long as you have end to end tests higher up. I should add that any new code you add should have unit tests around. E.g the new code added as per the refactor if needs be.

With good unit tests you can indeed refactor without fear, but we should not take the stance of never breaking any unit tests. Providing there is no functional change, break away! Such stance relies on end to end tests/pairing/some other process to ensure you are not breaking valid behaviour though.