Return to Answer

One of the dangers of testing is locking down an implementation. Tests should make it easier to refactor not harder. Tests that don’t focus on the public interface tend to lock down implementation.

Extending a class let’s you come in the back door and fiddle with non public stuff. That puts the focus of testing in the wrong place.

You may feel the private stuff needs testing. However, if you can’t achieve code coverage by testing the public interface then you have too much code. Get rid of the unreachable code. Maybe put it in a junk folder until you have a real use for it.

For example you have a protected constructor. Fine. If it exists for a reason then something somewhere uses it when it’s accessed publicly. Test that.

One of the dangers of testing is locking down an implementation. Tests should make it easier to refactor not harder. Tests that don’t focus on the public interface tend to lock down implementation.

Extending a class let’s you come in the back door and fiddle with non public stuff. That puts the focus of testing in the wrong place.

You may feel the private stuff needs testing. However, if you can’t achieve code coverage by testing the public interface then you have too much code. Get rid of the unreachable code. Maybe put it in a junk folder until you have a real use for it.

For example, you have a protected constructor. Fine. If it exists for a reason then something somewhere uses it when it’s accessed publicly. Test that.

One of the dangers of testing is locking down an implementation. Tests should make it easier to refactor not harder. Tests that don’t focus on the public interface tend to lock down implementation.

Extending a class let’s you come in the back door and fiddle with non public stuff. That puts the focus of testing in the wrong place.

You may feel the private stuff needs testing. However, if you can’t achieve code coverage by testing the public interface then you have too much code. Get rid of the unreachable code. Maybe put it in a junk folder until you have a real use for it.

For example you have a protected constructor. Fine. Something somewhere uses it when accessed publicly. Test that.

One of the dangers of testing is locking down an implementation. Tests should make it easier to refactor not harder. Tests that don’t focus on the public interface tend to lock down implementation.

Extending a class let’s you come in the back door and fiddle with non public stuff. That puts the focus of testing in the wrong place.

You may feel the private stuff needs testing. However, if you can’t achieve code coverage by testing the public interface then you have too much code. Get rid of the unreachable code. Maybe put it in a junk folder until you have a real use for it.

For example you have a protected constructor. Fine. If it exists for a reason then something somewhere uses it when it’s accessed publicly. Test that.

One of the dangers of testing is locking down an implementation. Tests should make it easier to refactor not harder. Tests that don’t focus on the public interface tend to lock down implementation.

Extending a class let’s you come in the back door and fiddle with non public stuff. That puts the focus of testing in the wrong place.

One of the dangers of testing is locking down an implementation. Tests should make it easier to refactor not harder. Tests that don’t focus on the public interface tend to lock down implementation.

Extending a class let’s you come in the back door and fiddle with non public stuff. That puts the focus of testing in the wrong place.

You may feel the private stuff needs testing. However, if you can’t achieve code coverage by testing the public interface then you have too much code. Get rid of the unreachable code. Maybe put it in a junk folder until you have a real use for it.

For example you have a protected constructor. Fine. Something somewhere uses it when accessed publicly. Test that.