Return to Answer

Do i skip testing these types of methods ... ?

If you can give me coverage I'm fine with that.

Unit tests always go against an API. Not everything has to be considered part of that API. How you remove stuff from being considered part of that API is up to you. Insisting it's always every non-private method is just hiding behind a brain dead rule. One that predates coverage tools.

There should be some deterministic lump of code we call a unit under that API that might have many methods and objects hiding inside it. You give me tests that cover it well and I'm not going to insist that every accessible method be called directly. Just show me a convincing coverage report.

Now that said, I'm also not opposed to developing a private method with unit tests. The thing is, keep those tests to yourself. Don't commit them. Because while they may help you write this method they'll lock down an implementation choice later that we don't want to be slaves too. We want to test behavior as loosely as we can. That enables refactoring. It's not fun having to rewrite tests every time you change code.

But understand, I don't feel that way because the method is private. I feel that way because I know that method is not part of the API that we care about testing. I don't really care about why it's not part of the API. Private, public, whatever, if it's not needed by the abstraction that we need to work then get this noise away from me.

Why do I have to be this paranoid? Because people are cowards when it comes to deleting old useless tests. They'd rather drag them around. That makes me conservative with what I allow. Document when a test should die well and maybe I'll relax a little. Maybe.

_{I’ve suffered in many shops that clung to that brain dead rule. I’m glad to see it eroding. When you let it rule you it changes the way you code. Many times we could have simplified a problem by adding a new object but wouldn’t because of the extra testing it would cause. We resorted to procedural programming just because we were forced to blindly adhere to that rule.}

Do i skip testing these types of methods ... ?

If you can give me coverage I'm fine with that.

Unit tests always go against an API. Not everything has to be considered part of that API. How you remove stuff from being considered part of that API is up to you. Insisting it's always every non-private method is just hiding behind a brain dead rule. One that predates coverage tools.

There should be some deterministic lump of code we call a unit under that API that might have many methods and objects hiding inside it. You give me tests that cover it well and I'm not going to insist that every accessible method be called directly. Just show me a convincing coverage report.

Now that said, I'm also not opposed to developing a private method with unit tests. The thing is, keep those tests to yourself. Don't commit them. Because while they may help you write this method they'll lock down an implementation choice later that we don't want to be slaves too. We want to test behavior as loosely as we can. That enables refactoring. It's not fun having to rewrite tests every time you change code.

But understand, I don't feel that way because the method is private. I feel that way because I know that method is not part of the API that we care about testing. I don't really care about why it's not part of the API. Private, public, whatever, if it's not needed by the abstraction that we need to work then get this noise away from me.

Why do I have to be this paranoid? Because people are cowards when it comes to deleting old useless tests. They'd rather drag them around. That makes me conservative with what I allow. Document when a test should die well and maybe I'll relax a little. Maybe.

_{I’ve suffered in many shops that clung to that brain dead rule. I’m glad to see it eroding. When you let it rule you it changes the way you code. Many times we could have simplified a problem by adding a new object but wouldn’t because of the extra testing it would cause. We resorted to procedural programming just because we were forced to blindly adhere to that rule. I’d love to see accessibility decisions less coupled to testing decisions. Just give me coverage.}

Do i skip testing these types of methods ... ?

If you can give me coverage I'm fine with that.

Unit tests always go against an API. Not everything has to be considered part of that API. How you remove stuff from being considered part of that API is up to you. Insisting it's always every non-private method is just hiding behind a brain dead rule. One that predates coverage tools.

There should be some deterministic lump of code we call a unit under that API that might have many methods and objects hiding inside it. You give me tests that cover it well and I'm not going to insist that every accessible method be called directly. Just show me a convincing coverage report.

Now that said, I'm also not opposed to developing a private method with unit tests. The thing is, keep those tests to yourself. Don't commit them. Because while they may help you write this method they'll lock down an implementation choice later that we don't want to be slaves too. We want to test behavior as loosely as we can. That enables refactoring. It's not fun having to rewrite tests every time you change code.

But understand, I don't feel that way because the method is private. I feel that way because I know that method is not part of the API that we care about testing. I don't really care about why it's not part of the API. Private, public, whatever, if it's not needed by the abstraction that we need to work then get this noise away from me.

Why do I have to be this paranoid? Because people are cowards when it comes to deleting old useless tests. They'd rather drag them around. That makes me conservative with what I allow. Document when a test should die well and maybe I'll relax a little. Maybe.

Do i skip testing these types of methods ... ?

If you can give me coverage I'm fine with that.

Unit tests always go against an API. Not everything has to be considered part of that API. How you remove stuff from being considered part of that API is up to you. Insisting it's always every non-private method is just hiding behind a brain dead rule. One that predates coverage tools.

There should be some deterministic lump of code we call a unit under that API that might have many methods and objects hiding inside it. You give me tests that cover it well and I'm not going to insist that every accessible method be called directly. Just show me a convincing coverage report.

Now that said, I'm also not opposed to developing a private method with unit tests. The thing is, keep those tests to yourself. Don't commit them. Because while they may help you write this method they'll lock down an implementation choice later that we don't want to be slaves too. We want to test behavior as loosely as we can. That enables refactoring. It's not fun having to rewrite tests every time you change code.

But understand, I don't feel that way because the method is private. I feel that way because I know that method is not part of the API that we care about testing. I don't really care about why it's not part of the API. Private, public, whatever, if it's not needed by the abstraction that we need to work then get this noise away from me.

Why do I have to be this paranoid? Because people are cowards when it comes to deleting old useless tests. They'd rather drag them around. That makes me conservative with what I allow. Document when a test should die well and maybe I'll relax a little. Maybe.

_{I’ve suffered in many shops that clung to that brain dead rule. I’m glad to see it eroding. When you let it rule you it changes the way you code. Many times we could have simplified a problem by adding a new object but wouldn’t because of the extra testing it would cause. We resorted to procedural programming just because we were forced to blindly adhere to that rule.}

Do i skip testing these types of methods ... ?

If you can give me coverage I'm fine with that.

Unit tests always go against an API. Not everything has to be considered part of that API. How you remove stuff from being considered part of that API is up to you. Insisting it's always every non-private method is just hiding behind a brain dead rule. One that predates coverage tools.

There should be some deterministic lump of code we call a unit under that API that might have many methods and objects hiding inside it. You give me tests that cover it well and I'm not going to insist that every accessible method be called directly. Just show me a convincing coverage report.

Now that said, I'm also not opposed to developing a private method with unit tests. The thing is, keep those tests to yourself. Don't commit them. Because while they may help you write this method they'll lock down an implementation choice later that we don't want to be slaves too. We want to test behavior as loosely as we can. That enables refactoring. It's not fun having to rewrite tests every time you change code.

Why do I have to be this paranoid? Because people are cowards when it comes to deleting old useless tests. They'd rather drag them around. That makes me conservative with what I allow. Document when a test should die well and maybe I'll relax a little. Maybe.

Do i skip testing these types of methods ... ?

If you can give me coverage I'm fine with that.

Unit tests always go against an API. Not everything has to be considered part of that API. How you remove stuff from being considered part of that API is up to you. Insisting it's always every non-private method is just hiding behind a brain dead rule. One that predates coverage tools.

There should be some deterministic lump of code we call a unit under that API that might have many methods and objects hiding inside it. You give me tests that cover it well and I'm not going to insist that every accessible method be called directly. Just show me a convincing coverage report.

Now that said, I'm also not opposed to developing a private method with unit tests. The thing is, keep those tests to yourself. Don't commit them. Because while they may help you write this method they'll lock down an implementation choice later that we don't want to be slaves too. We want to test behavior as loosely as we can. That enables refactoring. It's not fun having to rewrite tests every time you change code.

But understand, I don't feel that way because the method is private. I feel that way because I know that method is not part of the API that we care about testing. I don't really care about why it's not part of the API. Private, public, whatever, if it's not needed by the abstraction that we need to work then get this noise away from me.

Why do I have to be this paranoid? Because people are cowards when it comes to deleting old useless tests. They'd rather drag them around. That makes me conservative with what I allow. Document when a test should die well and maybe I'll relax a little. Maybe.