Manual:Writing testable PHP code
<translate> PHPUnit testing</translate>
<translate> Contents</translate>
- <translate> Running the tests</translate>
- <translate> Generate code coverage</translate>
- Writing testable PHP code
- <translate> Writing tests</translate>
- <translate> Continuous integration</translate>
- <translate> Understanding build failures</translate>
- <translate> Appendix</translate>
(<translate> how to help, resources..</translate>)
<translate> Tools</translate> <translate>
</translate>
Some notes on writing testable, code, to be expanded on at some point.
Don't assume global context
Accessing global variables (e.g. $wgRequest) without declaring them first with the global keyword will cause failures and E_NOTICE messages to be generated if they are accessed in a non-global context.
Don't create new global variables
While putting information in global variables seems easy, it makes the code less predictable. By relying on global variables, you are making it difficult to isolate functionality. A singleton class is better for testing (but, still, less than ideal).
Rely only on direct inputs
While this is not always achievable, it is best to write code that depends only on direct inputs. That is, a class only uses the information it is passed and does not rely on singletons or globals to get “out-of-band” information.
Do not use exit()
Exiting from a script abruptly should almost never be done. Doing so will make your code untestable by PHPUnit. If your code encounters an unexpected error, the proper thing to do is throw an exception like:
throw new MWException( "Oh noes!" );
This will allow PHPUnit and MediaWiki to exit properly and provide informative information such as stack traces to developers.
