Why mark a method as public?

If it's so it can be tested you're designing an API for testers. Not to be used. If it's public it can be accessed from all sorts of places and has to provide all those places with what they expect. Ensuring that is a lot of work.

Why mark a method as private?

If it's so you don't have to test it you're just being lazy. Being private means you don't have to look far to see how it's used. It makes analysis easy. Don't give that up easily.

How much testing is enough?

A private method should service some public method. If you can't fully exercise the private method from the public one then the private one is allowing to much. It's OK to reject negative numbers because the public method never passes them. You don't have to force negative numbers into the private method just to watch it throw an otherwise unreachable exception. Exercising defensive coding is a poor excuse to blow up your accessability.

When to switch?

However, popular private methods suffer from the same problem that public methods do. They're wide use means they serve many masters. This is when it's worth promoting them to public. Not because they need testing and this is the only way. But because they need their expectations locked down in one place.

If you're wondering how a private method becomes popular you haven't seen the 1000+ line monsters I have. Count yourself lucky.

If a private method is making some public methods pass their tests and some others fail then what exactly is the fix?

Understand, just because a method is marked public doesn't mean it's intended for consumption outside. Sometimes an object abstracts away a whole bunch of other objects (see façade pattern). But remember, that kind of encapsulation isn't free. Setting that up is work.

I remain convinced that testing is not a good argument to change a methods accessibility. However, if you have multiple tests of multiple public methods exercising a private method you may benifit from admiting this things life isn't so private anymore. Making it public allows you to lay down the law on the behavior expected from this thing. But now you have to deal with it being public.

Why mark a method as public?

If it's so it can be tested you're designing an API for testers. Not to be used. If it's public it can be accessed from all sorts of places and has to provide all those places with what they expect. Ensuring that is a lot of work.

Why mark a method as private?

If it's so you don't have to test it you're just being lazy. Being private means you don't have to look far to see how it's used. It makes analysis easy. Don't give that up easily.

How much testing is enough?

A private method should service some public method. If you can't fully exercise the private method from the public one then the private one is allowing too much. It's OK to reject negative numbers because the public method never passes them. You don't have to force negative numbers into the private method just to watch it throw an otherwise unreachable exception. Exercising defensive coding is a poor excuse to blow up your accessibility.

When to switch?

However, popular private methods suffer from the same problem that public methods do. Their wide use means they serve many masters. This is when it's worth promoting them to public. Not because they need testing and this is the only way. But because they need their expectations locked down in one place.

If you're wondering how a private method becomes popular you haven't seen the 1,000+ line monsters I have. Count yourself lucky.

If a private method is making some public methods pass their tests and some others fail then what exactly is the fix?

Understand, just because a method is marked public doesn't mean it's intended for consumption outside. Sometimes an object abstracts away a whole bunch of other objects (see façade pattern). But remember, that kind of encapsulation isn't free. Setting that up is work.

I remain convinced that testing is not a good argument to change a method's accessibility. However, if you have multiple tests of multiple public methods exercising a private method you may benefit from admitting this thing's life isn't so private any more. Making it public allows you to lay down the law on the behavior expected from this thing. But now you have to deal with it being public.

Why mark a method as public?

If it's so it can be tested you're designing an API for testers. Not to be used. If it's public it can be accessed from all sorts of places and has to provide all those places with what they expect. Ensuring that is a lot of work.

Why mark a method as private?

If it's so you don't have to test it you're just being lazy. Being private means you don't have to look far to see how it's used. It makes analysis easy. Don't give that up easily.

How much testing is enough?

A private method should service some public method. If you can't fully exercise the private method from the public one the private one is allowing to much. It's OK to reject negative numbers because the public method never passes them. You don't have to force negative numbers into the private method just to watch it throw an otherwise unreachable exception. Exercising defensive coding is a poor excuse to blow up your accessability.

When to switch?

However, popular private methods suffer from the same problem that public methods do. They're wide use means they serve many masters. This is when it's worth promoting them to public. Not because they need testing. But because they need their expectations clearly locked down.

If you're wondering how a private method becomes popular you haven't seen the 1000+ line monsters I have. Count yourself lucky.

If a private method is making some public methods pass their tests and some others fail then what exactly is the fix?

Understand, just because a method is marked public doesn't mean it's intended for consumption outside. Sometimes an object abstracts away a whole bunch of other objects (see façade pattern). But remember, that kind of encapsulation isn't free. Setting that up is work.

I remain convinced that testing is not a good argument to change a methods accessibility. However, if you have multiple tests of multiple public methods exercising a private method you may benifit from admiting this things life isn't so private anymore. Making it public allows you to lay down the law on the behavior expected from this thing. But now you have to deal with it being public.

Why mark a method as public?

If it's so it can be tested you're designing an API for testers. Not to be used. If it's public it can be accessed from all sorts of places and has to provide all those places with what they expect. Ensuring that is a lot of work.

Why mark a method as private?

If it's so you don't have to test it you're just being lazy. Being private means you don't have to look far to see how it's used. It makes analysis easy. Don't give that up easily.

How much testing is enough?

A private method should service some public method. If you can't fully exercise the private method from the public one then the private one is allowing to much. It's OK to reject negative numbers because the public method never passes them. You don't have to force negative numbers into the private method just to watch it throw an otherwise unreachable exception. Exercising defensive coding is a poor excuse to blow up your accessability.

When to switch?

However, popular private methods suffer from the same problem that public methods do. They're wide use means they serve many masters. This is when it's worth promoting them to public. Not because they need testing and this is the only way. But because they need their expectations locked down in one place.

If you're wondering how a private method becomes popular you haven't seen the 1000+ line monsters I have. Count yourself lucky.

If a private method is making some public methods pass their tests and some others fail then what exactly is the fix?

Understand, just because a method is marked public doesn't mean it's intended for consumption outside. Sometimes an object abstracts away a whole bunch of other objects (see façade pattern). But remember, that kind of encapsulation isn't free. Setting that up is work.

I remain convinced that testing is not a good argument to change a methods accessibility. However, if you have multiple tests of multiple public methods exercising a private method you may benifit from admiting this things life isn't so private anymore. Making it public allows you to lay down the law on the behavior expected from this thing. But now you have to deal with it being public.