Unit Testing – How to Test Logic in CRUD Applications

Variation on (a).

Have a test db or subsection of the db that can be used for testing. When you are setting up your tests, have a routine that initializes the DB as you need it to begin testing (this can be done before each test, as appropriate). This may include deleting data, inserting data, etc. Then run your tests. In the Teardown phase, clean up after yourself. Can be repeated as much as is needed, without risk of disrupting live system (not a good idea to test using data in the database that is needed for anything else).

Until recently, I would have just pointed you at plenty of other existing questions that say that you generally shouldn't need access to any private stuff, in order to write unit tests - as the whole point of tests is to test the public (and protected) interface.

For example, in the question how to unit-test private methods in jquery plugins?, there is this answer:

The same applies here as with any other language and testing privates: To test private methods, you should exercise them via the public interface. In other words, by calling your public methods, the private methods get tested in the process because the public methods rely on the privates.

Generally private methods are not tested separately from the public interface - the entire point is that they are implementation details, and tests should generally not know too much about the specifics of the implementation

In your specific case, you say:

Since the data is private, I can only add things via the public interface of the object. This run codes that need not be run during a unit test and in some case is just a copy and paste from another test.

I would be cautious about having any tests that avoided code that normally needs to be run - for fear that your tests would spuriously pass, due to some difference between the test behaviour and the real world.

Having said all that, I recently learned about a really excellent article on writing testsuite called The Way of Testivus. It's a PDF that's only 12 pages long, and a really easy and enjoyable read.

What's relevant here is the section entitled "Sometimes, the test justifies the means" - in the context of violating encapsulation to enable testing. I highly recommend it.

(Another favourite of mine is "An ugly test is better than no test.")

So, in your context, if you still decide you really want a different way to set up data purely for tests, it might be reasonable to add a public setter method, specifically documented as only existing to aid writing of tests.