Refactor internals so statics work with internal objects

[funkatron]

Right now it would be difficult -- if not impossible -- for FUnit to test itself. This is generally a Bad Thing, I think. These are some notes on a potential solution.

One reason it's so challenging is that using statics for everything, including internal tracking of tests and results, means there can only be one of everything, including the array of run tests, assertion tracking, etc.

Note that a lot of the ideas here would be similar to how Slim's $app objects are created and tracked

I suspect that a good approach would be to have a TestSuite object internally. When we call FUnit::test(), tests would be attached to that object.

class TestSuite

• tests (attached with FUnit::test())
• setup_func (attached with FUnit::setup())
• teardown_func (attached with FUnit::teardown())
• (new) before - runs before the suite starts (attached with FUnit::before() (new))
• (new) after - runs after the suite finished (attached with FUnit::after() (new))

By default, everything is attached to a 'default' TestSuite. You can start separate suite, though, by calling FUnit::test_suite($name) (new). All subsequent calls to methods like FUnit::test(), FUnit::setup(), and ``FUnit::teardown()would apply to that newTestSuite` object.

Calling FUnit::run() would "close" the current suite. If FUnit::test() is called after a run, a new TestSuite would automatically be created.

In addition, there should be a way to retrieve a TestSuite by the name (FUnit::getSuite($name)), and then directly attach tests and run the suite (probably via standard OOP method calls). That way we could create one test suite that makes FUnit static calls, and make assertions against a second test suite created by those calls.

[funkatron]

I've made a lot of progress on this. Things are testable to some extent, although testing the test building methods or report output is challenging. Tests do run within separate suites, and suites are auto-created if one isn't already initiated.