Download the PHP package filisko/testable-functions without Composer
On this page you can find all versions of the php package filisko/testable-functions. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package testable-functions
Testable PHP functions
A library that provides an approach for testing code that heavily relies on PHP's built-in functions or language constructs (great for "include/require-oriented architectures", such as legacy projects) that are normally really hard to test.
There are no excuses for not testing PHP functions anymore!
Requirements
- PHP >= 7.1
Installation
This package is installable and autoloadable via Composer as filisko/testable-functions.
Usage
The package provides two main classes: Functions used in production and FakeFunctions used for testing.
These two classes allow you to use PHP's built-in functions and language constructs (require_once, include, echo, print, etc.) without having to worry about tests.
You can see a basic example here of production code and its tests, along with many comments to make the example clearer.
Functions class
This class is like a proxy for PHP functions. It uses the __call hook internally to forward function calls to PHP, and it also wraps PHP's language constructs like require_once inside functions so that they can be testable.
Using this class can be particularly useful for code that involves I/O operations because the results of those operations can be easily altered for testing purposes later on.
Imagine the following production code:
Then, by using the FakeFuctions class in the testing environment, the results of the functions can be easily altered like this:
Legacy projects are usually "require/include oriented architectures", so the following can be very handy.
As you've read before, this package supports PHP language constructs (parsed differently than functions by PHP) wrapped in functions:
This makes it possible to alter them for testing purposes:
Keep in mind that loading things like globals will make them available across all the other tests, and you may not want this. To solve this issue, use PHPUnit's docblocks for each test method shown below:
- globals (
@backupGlobals) - classes or functions (
@runInSeparateProcess,@preserveGlobalState disabled) -
static variables or properties (
@backupStaticAttributes)
Furthermore, passing --process-isolation to PHPUnit will globally apply @runInSeparateProcess to every single test, but it's not a good idea to do it unless you know what you're doing.
FakeFunctions class
As shown in the previous examples, this class is used as a replacement for the Functions class in the testing environment, but it also provides many helper methods for the tests.
Why to use this package?
Why to choose this package over a hundred other tools out there?
Because we prefer simplicity over complicated mocking tools, and we just want enough to accomplish our goal.
This is a common example from other mocking tools:
While for us it's simply:
Cons
Injecting Functions into the class.
For some, this is a con; for us, it's simply how it should be. We follow the DI principle for almost everything, so why not for this?
We consider it a good practice to always set the Functions dependency in the constructor as the last one, so that "it doesn't get in our way" and also set it as default so that nothing needs to be passed to the constructor in production. Only when testing.
PHP functions autocomplete is lost in IDEs
This is a natural consequence of this lib's approach. PHP functions autocomplete is lost given that we use a 'Proxy' class.
However, we developed a tool that generates a 'Stub' file with all the PHP functions so that your IDE keeps the autocomplete for them.
All you have to do is run the following command:
Keep in mind that the functions that it loads in the Stub file are based on the active PHP extensions at runtime and loaded by composer.
Using this tool is optional, but it's recommended.
Other testing utilities
- PSR-3 fake logger: filisko/fake-psr3-logger
- PSR-15 middleware dispatcher: middlewares/utils (used in conjuction with PSR-7 and PSR-17)
- PSR-16 fake cache: kodus/mock-cache
License and Contribution
Please see CONTRIBUTING for contributing details.
The MIT License (MIT). Please see LICENSE for more information.
