Testing strategy for large application with few public methods?

Question

Hi, I'm working on a project which I'm really not sure how to unit test. It's an unobtrusive tag based framework for wiring up events between models, views and delegates in a GUI system.

Basically you have one large json file which is used describes all of the events, event handlers and bindings. The user creates their models, views and delegates all of which have no knowledge of the framework. The JSON file is passed to an init() methods, then the framework creates all of the instances needed and takes care of all the bindings, listeners etc.

The problems I have are two fold:

1) There is basically only a single public method in the framework, everything else is communicated through the mark-up in the JSON file. Therefore I have a very small testing surface for what is a large and complicated application.

2) One of the big roles of the application is to instantiate class's if they haven't been instantiated previously and cached. This means that I need real classes in my test code, simple mocks aren't going to cut it.

At the moment I'm considering a couple if solutions. The first is start testing the private methods. The second is to just stub the constructors.

Any one else have any ideas?

Answer 1

list the features (scenarios, use-cases, whatever you want to call them) of the system, and establish JSON data/frameworks for each feature. These are your unit tests.

Answer 2

1) There is basically only a single public method in the framework, everything else is communicated through the mark-up in the JSON file. Therefore I have a very small testing surface for what is a large and complicated application.

How is that possible? is this entire complicated framework stored in one class? if there are several classes involved, how do they share information without public methods?

A constructor is a public method too, by the way.

Are you just passing around the JSON object? that would couple your framework to the information source too tightly. You should have one class parsing the JSON, and the rest communicating without knowledge of the data source (via testable public methods).