Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save arielmagbanua/f0af4ea51801cf89c71be3c76427afa9 to your computer and use it in GitHub Desktop.
Save arielmagbanua/f0af4ea51801cf89c71be3c76427afa9 to your computer and use it in GitHub Desktop.
General Testing Practice
OK that makes sense. I'm not 100% familiar with PHPUnit & didn't notice the @Depends comments etc. I'm fine with that.
There will always be exceptions to the rule, but in general we don't want to be testing private variables IMO. In my mind, the normal progression of TDD I'd generally start from the "outside of the black box", and work my way in only if I really have to. E.g. calling methods from the interface first - e.g something like this (TEST=update test, CODE=update code base):
TEST: Instantiate Flow\Schema\Register\Blueprint
CODE: Create empty version of that class with a constructor
TEST: $definition = $blueprint->definitions();
CODE: create definitions method doing nothing
TEST: assert $definition is a collection
CODE: instantiate $this->definitions = collection, and update definitions method to return it
TEST: .... etc
(probably in reality you would load some definitions before step #3 but its just there for example)
Ultimately I don't really care how the definitions method works - only that if I call it, it returns me a collection of definitions.
We could write more detailed tests that go into its inner workings, and perhaps for a really complex classes we might have to (or just simplify the class), but the more detailed the test is, the more tightly coupled to the class implementation it is, the more brittle it is & the more maintenance it will need to stop false positives
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment