"Smart contracts" implement legal expectations, forming an agreement as to state between 2+ computers, and when that state changes. It is unfortunate that some are trying to shoehorn the idea unmodified into the legal space, bc as explained elsewhere, "contract" is loaded with legislative and judicial baggage,--not to mention centuries of academic gloss/glop. At this early stage, we can be certain that smart contracts will be powerful tools to assure pre-ordained outcomes, but without AI, the only way to do that is to make them as dumb as possible. I would argue that general acceptance will depend on them being as dumb as possible, bc lawyers are slow to shift and highly risk-adverse.

The outcome of engagement between 2+ computers can't be vague: without either an "oracle" or resort to arbitration (which sort of defeats the purpose), all you get is moosh. So, we need a lot more lawyer-programmers to ensure usefulness and community consensus around how, when and why we will recommend clients integrate and rely on them. Once that happens, am absolutely certain they will be disruptive and increase efficiency,--as well as cause rewriting of huge chunks of commercial law and best practices. Hold on to your hats!!

If they are internal functions you can inherit them and test them, if they are private functions, I believe the only way to unit test them is to make them public/internal, test them and then change them back to private once the tests are passing.

Another way to go about it would be to refactor your code so that the private functions are part of a library that you import into the contract. That way the functions are public in the library but not exposed in the actual contract.