The testing tools (only the code hacker at this time) have been moved
from 'src' to 'tests/Tools', since many opcode cache plugins
load the whole src folder in production.
Also, an extra autoloader is set in the tests bootstrap so that
the 'tests/Tools' directory corresponds, using PSR4, to the
'Automattic\WooCommerce\Testing\Tools' namespace.
- Add methods to temporarily disable and reenable the code hacker.
The code hacker is causing issues in some tests that perform
write operations to the local filesystem. Since this happens only
in a few cases, the easiest fix is to temporarily disable the
code hacker when that happens. This commit adds two new methods
for that in `WC_Unit_Test_Case`: `disable_code_hacker` and
`reenable_code_hacker`.
These methods use a disabling requests count so that the hacker
isn't enabled before it should. E.g. you call `disable`, then
a helper method that does `disable` and `enable`, then `enable` -
then only the last `enable` will have effect.
- `CodeHacker::add_hack` has now a boolean `persistent` parameter.
Persistent hacks won't be cleared by `clear_hacks`.
- `CodeHackerTestHook::executeAfterTest` will now disable the hacker
only if no persistent hacks are registered.
- The existing `file_copy` method is made static for consistency.
- `CodeHacker::restore` method renamed to `disable` for clarity.
The unit testing bootstrap loads and initializes WooCommerce, this
loads a bunch of code files that can't then be hacked in the test hooks.
A workaround is provided in this commit for the case of hacking
static methods. A new StaticWrapper class is created that allows
defining mock methods after the code file has been loaded.
This is applied to all classes from a fixed list in the bootstrap,
before WooCommerce is initialized. The list should be kept up to date
with the list of classes that require such workaround.
- Fix how CodeHackerTestHook::executeBeforeTest parses the test name,
to account for warnings and tests with data sets.
- CodeHackerTestHook now includes a executeAfterTest hook that
disables the code hacker (needed to prevent it from inadvertently
altering further tests). Also, clear_hacks is executed in
executeBeforeTest for the same reason.
- CodeHacker gets restore, clear_hacks and is_enabled methods
to support the changes in CodeHackerTestHook.
- FunctionsMockerHack fixed so that it doesn't modify strings
that are class method definitions.
- Added the WC_Unit_Test_Case::file_copy method, it must be used
instead of the PHP built-in "copy" in tests, otherwise tests
that run with the code hacker active will fail.
This is something to investigate.
Now @hack class and method annotations can be used to register
code hacks as an alternative to using before_ methods.
The syntax is /* @hack HackClassName param1 param2 */
where parameters will be passed to the class constructor.
If the class name ends with "Hack", then that suffix can be
omitted (e.g. "Foo" can be specified instead of "FooHack").
The "code hacker" is a class that hooks on filesystem events
(using stream_wrapper_unregister) in order to allow for dynamically
modifying the content of PHP code files while they are loaded.
The code hacker class allows registering hacks, which are
functions that take source code as input and return the modified code.
A hack can be a standalone function or a class with a "hack" method.
A few hacks are provided off the shelf. One allows mocking standalone
PHP functions (WP, WOO or not), another one allows mocking static
methods, and there's the one that removes the "final" qualifier
from a class definition. This helps unit testing stuff that would
otherwise be quite hard to test.
Since we were converting the field to lowercase we ended up inserting meta in all lowercase, regardless of what it was in the CSV file. We should only be using the normalized field name when looking at the default columns, and should instead rely on a case-insensitive regex for the special columns.
One thing to note is that we're still defaulting the $headers array to the normalized field, as we don't want to change what is being passed to the filter for unmapped columns.
Since those Notes were created because of WC Admin and the display is handled by WC Admin, it does not make sense to test them without WC Admin.
In addition, the data store that handles these Notices is not loaded without WC Admin.
All titles and questions in the new onboarding wizards only capitalise names and the first letter of the sentence. This seemed a tiny bit off. (Literally tiny.)
Changed "Build a Better WooCommerce" to "Build a better WooCommerce"
* Merge wc api authorization headers with given headers
* Add put method to WC_Helper_API
* Add unit test coverage around WC_Helper_API request methods
* Add tests for WC_Helper_API url method
Since the tokens are replaced in a first-discovered first-replaced order, we may accidentally create tokenized paths like '{{ABSPATH}}/test' instead of the desired '{{WP_CONTENT_DIR}}test'. By ordering them according to specificity however, we ensure that we tokenize as much of the path as possible.
Initially it was made more precise to avoid calculating estimates for incomplete addresses. Due to some bad working in template files though, as well as historical precedent, we need to change it back.
Instead of comparing all tables that exist with all tables that are registered with `WC_Install::get_tables()` (which was only introduced a few versions ago in #19436), rewrite the test to verify that all of the tables *registered* actually exist within the database.
This will prevent tests from failing when, for example, they're run against databases that may or may not have additional plugins installed/activated. This also prevents tests from failing when running WooCommerce 4.x (e.g. with WooCommerce Admin) on WordPress < 5.3, since the tables are created but the callback to register the custom tables is never hooked.