Created
July 3, 2019 22:59
-
-
Save arielmagbanua/f0af4ea51801cf89c71be3c76427afa9 to your computer and use it in GitHub Desktop.
General Testing Practice
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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