@diosmosis opened this Pull Request on June 19th 2015 Member

This PR includes:

  1. Ability for environments to stack in StaticContainer. This allows us to embed environments (to some level). When a new Environment is created, instead of replacing the StaticContainer instance, it pushes the instance to an internal stack. There is an Environment::destroy() method that must be explicitly called to remove the entry.
  2. Fix the way Fixture::provideContainerConfig() results are used to override DI. Instead of creating a new Fixture instance, we use the instance in the test case class. This way, the fixture's properties will be set properly in child processes.
  3. Reload test vars before manipulating an environment, so changes to test vars will be seen when creating new environments (ie, create Environment, change vars, create embedded Environment will use new vars instead of the original).
  4. Allow embedded environments to override GlobalSettingsProvider in tests by making TestingEnvironmentManipulator only override the provider if it has to. Previously, it would always create its own GlobalSettingsProvider, so the embedded environment's custom one would be replaced.
  5. Change to the way all provideContainerConfig() results are added. Instead of using array_merge, we add them to an array of definition arrays. This way, fixtures & tests can both use DI\add to the same array, and one won't overwrite the other. Also allows doing the same sort of thing w/ DI\decorate.
  6. Moved FakeCliMulti to its own file so it can be reused.
  7. Some other smaller bug fixes to DI test code. Commit messages have more info.

Going commit by commit to review might be hard for the first two or three commits, but I think is the best way to review.

@mnapoli commented on June 19th 2015 Member

Looks good to merge (needs a rebase). The TestingEnvironmentManipulator and stuffs around it starts to get a little complex, harder to follow everything. Hopefully with time we can simplify it more and more.

@diosmosis commented on June 19th 2015 Member

Ok, I will merge this PR.

The TestingEnvironmentManipulator and stuffs around it starts to get a little complex, harder to follow everything.

Can you let me know what specifically is confusing about it? Would be really useful to have an outside perspective at this point, since I am right now very, very immersed in this code. Is it clearer than the TestingEnvironment.php code that was there before?

This Pull Request was closed on June 20th 2015
Powered by GitHub Issue Mirror