I am working with Zend Framework 2 and I want to run tests for all of my modules in PhpStorm 5.0.4. I have PhpStorm set up to check for tests in myproject/module and it successfully finds my tests. The problem is that it doesn't read my configuration file within each module, which is needed (it points to a bootstrap file).
Here is the directory structure for a module (source):
/module
/User
/tests
/UserTest
/Model
/UserTest.php
Bootstrap.php
phpunit.xml.dist
TestConfig.php.dist
When I run the test, it gives me an error because Bootstrap.php is not run prior to running UserTest.php. All of the files are correct, because if I cd to /myproject/module/User/tests/ and run phpunit within the Terminal, it works fine.
I would like it to use the configuration (and thereby bootstrap) within each module. I tried to use the --configuration option with a relative path, but I couldn't get it to work.
Here is my current configuration:
Any pointers on how I can run the configuration file (and bootstrap) when a module is being tested? That is, a module has its own configuration file and bootstrap.
Thanks in advance.
PHP Storm 7 assumes that you will only need ONE default bootstrap file and thus does not enable individual bootsrap files DIRECTLY for each PHPUnit test configuration.
However, zf2 conducts tests on a per module basis. Thus, after you set the defaults to the first module the other modules don't work. The way around this is to
Remove the default options in File|Settings|PHP|PHPUnit
You don't have to remove the default configuration file but you must EMPTY OUT and uncheck the default bootstrap file. Just unchecking will not be enough
Go Run|Edit Configurations (there are other shortcuts to this box)
For each module you have to create a test configuration. For example, you'll have the standard Application Module and thus an "Application Module Test" for it, maybe an Admin Module and then an "Admin Module Test" for that
For each test (assuming standard zf2 directory structure)
a. Test Scope: Directory
b. Directory: C:\wamp\www\PROJECT-NAME\module\MODULE-NAME\test
c. Check "Use alternative configuration file:"
d. Enter C:\wamp\www\PROJECT-NAME\module\MODULE-NAME\test\MODULE-NAMETest\phpunit.xml.dist
e. In "Test Runner options", enter "--bootstrap C:\wamp\www\PROJECT-NAME\module\MODULE-NAME\test\MODULE-NAMETest\Bootstrap.php"
Repeat for next module
The issue here is that as long as the default bootsrap field has an entry, phpstorm will add that as default as a --bootstrap option AFTER whatever you put in the case specific Test Runner options. So, no matter what you do, you end up running the wrong bootstrap file everytime except for the first/default test case
Hope this helps
Unless I missed something, you'll have to set up a test configuration for each module. In your case, you have myproject. Instead, you'll want one for each module, and then set up the configuration for each (Use alternative configuration file).
I make use of the environment variables option in the run configuration to to define a value I can use within a global bootstrap.php to pull in requirements specific to a given module or section of the application.
class GlobalBootstrap
{
private static $applicationSections = [
'section_a',
'section_b',
'section_c'
];
public static function init()
{
$localMethod = self::fetchLocalMethod();
if (!is_null($localMethod)) {
self::$localMethod();
} else {
throw new Exception(
__CLASS__
. '::'
. __FUNCTION__
. 'Says: No local method has been defined for this test section'
);
}
}
private static function fetchLocalMethod()
{
$section = getenv('APPLICATION_SECTION');
if (is_null($section) || !in_array($section, self::$applicationSections)) {
return null;
}
$section = preg_replace("/[^a-zA-Z]+/", "", $section);
$method = 'bootstrap' . ucfirst(strtolower($section));
return $method;
}
/**
* Section specific methods
*/
protected static function bootstrapSectiona()
{
require __DIR__ . '/../../{section_a}/module/Test/Bootstrap.php';
}
}
GlobalBootstrap::init();
Any arbitrary variable and value can be created and then referenced in your bootstrap.php using: getevn(VARIABLE_NAME); This saves a lot of long-winded configuration in PHPStorm, but culd potentially get equally as complex if you're relying on a lot of differing bootstrap functionality.
Related
I am having problems using Jest manual mocks (the one in a parallel __mocks__ directory) in my project.
I think I understand how to use it and it actually works fine if I remove a single line in a file specified in the Jest setupFiles array.
In that file a global helper is installed (into global.createComp) that uses the vuex store.
This is a vue + vuex project but even running the stripped down spec using only jest gives unexpected results.
Can somebody look at my minimal reproducible example repo at https://github.com/thenoseman/jest-manual-mock-not-working, do a npm i and npm run test:unit and help me understand why the mock is not active?
You can find the line that need to be commented out in test/unit/support/helpers.js.
Also the README shows a screenshot and further explains what the problem looks like.
setupFiles are evaluated before test files. As the reference states,
A list of paths to modules that run some code to configure or set up the testing environment. Each setupFile will be run once per test file. Since every test runs in its own environment, these scripts will be executed in the testing environment immediately before executing the test code itself.
JavaScript modules are evaluated once on first import. Importing #/store/modules/internetAtHome in helpers.js results in importing original #/api/DslService.
The mock in test file doesn't affect #/api/DslService because it has already been evaluated earlier:
jest.mock("#/api/DslService");
import DslService from "#/api/DslService";
In case helpers.js needs mocked #/api/DslService, jest.mock needs to be moved there.
In case helpers.js needs original #/api/DslService but tests need mocked one, the module (and any module that depends on it) needs to be re-imported with jest.resetModules or jest.isolatedModules:
jest.mock('#/api/DslService');
let DslService;
jest.isolateModules(() => {
DslService = require("#/api/DslService").default;
});
...
For a module that was imported with original implementation and needs to be re-imported as a mock, jest.requireMock can be used, it doesn't need jest.mock('#/api/DslService'):
let DslService = jest.requireMock("#/api/DslService").default;
...
I have created a simple Puppet 4 class and a unit test to go along with it as follows (after executing touch metadata.json; rspec-puppet-init while in modules/test/):
# modules/test/manifests/hello_world1.pp
class test::hello_world1 {
file { "/tmp/hello_world1":
content => "Hello, world!\n"
}
}
# modules/test/spec/classes/test__hello_world1_spec.rb
require 'spec_helper'
describe 'test::hello_world1' do
it { is_expected.to compile }
it { is_expected.to contain_file('/tmp/hello_world1')\
.with_content(/^Hello, world!$/) }
end
I can successfully run the unit test by executing rspec spec/classes/test__hello_world1_spec.rb while in modules/test/.
I would now like to proceed to a slightly more advanced class that uses code from another module, namely concat (the module has arleady been installed in modules/concat):
# modules/test/manifests/hello_world2.pp
class test::hello_world2
{
concat{ "/tmp/hello_world2":
ensure => present,
}
concat::fragment{ "/tmp/hello_world2_01":
target => "/tmp/hello_world2",
content => "Hello, world!\n",
order => '01',
}
}
# modules/test/spec/classes/test__hello_world2_spec.rb
require 'spec_helper'
describe 'test::hello_world2' do
it { is_expected.to compile }
# ...
end
When I attempt running this unit test with rspec spec/classes/test__hello_world2_spec.rb while in modules/test I receive an error message that includes:
Failure/Error: it { is_expected.to compile } error during compilation:
Evaluation Error: Error while evaluating a Resource Statement, Unknown
resource type: 'concat'
I suspect the root cause is that rspec cannot find the other module(s), because it has not been told a "modulepath".
My question is this: How exactly am I supposed to start unit tests, especially ones that require access to other modules?
Install the PDK for your platform from its download page. Re-create the module using pdk new module, and pdk new class, or by following the Guide.
Now, I come to what is probably the immediate problem in your code: your code depends on a Puppet Forge module, puppetlabs/concat but you haven't made it available. The PDK module template already has pre-configured puppetlabs_spec_helper to load fixtures for your module.
To tell puppetlabs_spec_helper to get it for you, you need a file .fixtures.yml with the following content:
fixtures:
forge_modules:
stdlib: puppetlabs/stdlib
concat: puppetlabs/concat
Note that you also need puppetlabs/stdlib, because that is a dependency of puppetlabs/concat.
If you want to explore more fixture possibilities, please refer to puppetlabs_spec_helper's docs.
With all of this in place, and integrating the code samples and test content you posted into the initial code skeletons provided by the PDLK, your tests will all pass now when you run:
$ pdk test unit
Note that I have written all about the underlying technologies, in a blog post, showing how to set up Rspec-puppet and more from scratch (ref), and it still appears to be the most up-to-date reference on this subject.
To read more about rspec-puppet in general, please refer to the official rspec-puppet docs site.
I need a good practice to deal with my issue.
The issue is: I need to run automatic tests against a site. The site has different configurations that completely change its design (on some pages). For example I can config 2 different pages of login. And I need to test them both.
First of all I must make sure that a correct test is run against a correct configuration. So before each test I need to change site's config. It is not good if I have a thousand of test.
So a solution that comes to my mind is to not reconfigure the site each time but do it once and run all the tests that are corresponding to this configuration. But this solution doesn't seems to me as an easy one to make.
For now what I did is: I created a method that is run once before all the other tests and in this method I configure the site to make config that are used in the majority of the tests. All the other tests for now change the config before execution and after execution they change it back. It's not good at all.
To do so I used NUnit3 SetUpFixture and OneTimeSetUp attributes:
/// <summary>
/// Runs once before all the test in order to config the environment
/// </summary>
[SetUpFixture]
public class ConfigTests
{
[OneTimeSetUp]
public void RunBeforeAnyTests()
{
IWebDriver driver = new ChromeDriver();
try
{
//Here I config the stie
CommonActions actions = new CommonActions(driver);
actions.SwitchOffCombinedPaymentPage();
driver.Dispose();
}
catch (Exception)
{
driver.Dispose();
}
}
}
What I thought after this is that I'll be able to send parameters to SetUpFixture but first of all it's impossible and second of all it won't resolve the problem as this feature will just be run twice and the tests will be run against the last configuration.
So guys, how to deal with a site testing that has a lot of configurations?
I'd use a test run parameter from the command-line (or in the .runsettings file if you are using the VS adapter) Your SetUpFixture can grab that parameter and do the initialization and any individual fixtures that need it can grab it as well.
See the --params option to nunit3-console and the TestContext.TestParameters property for accessing the values.
This answers your "first of all it's impossible" part. I didn't answer "second of all... " because I don't understand it. I'll add more if you can clarify.
I'm using log4net, trying to get logging in my unit tests. If I manually call
log4net.Config.XmlConfigurator.Configure();
Since that works, that seems to eliminate all of the "bad config, config location" issues.
it works, but there are a large number of test classes, so that is not good.
I added
[assembly: log4net.Config.XmlConfigurator(Watch=true)]
to the assemblyinfo of my test project, but when I run (either via native MSTest, or Resharper test runner) I get no logging.
Help?
Source
[AssemblyInitialize()]
public static void MyTestInitialize(TestContext testContext)
{
// Take care the log4net.config file is added to the deployment files of the testconfig
FileInfo fileInfo;
string fullPath = Path.Combine(System.Environment.CurrentDirectory, "log4net.config");
fileInfo = new FileInfo(fullPath);
As it says in the documentation for assembly attributes
Therefore if you use configuration attributes you must invoke log4net
to allow it to read the attributes. A simple call to
LogManager.GetLogger will cause the attributes on the calling assembly
to be read and processed. Therefore it is imperative to make a logging
call as early as possible during the application start-up, and
certainly before any external assemblies have been loaded and invoked.
Because the unit test runners load the test assembly in order to find and the tests, it isn't possible to initialise log4net using an assembly attribute in unit test projects, and you will have to use the XmlConfigurator.
Edit: as linked in a comment by OP this can be done in one place for the whole test project by using the AssemblyInitializeAttribute
What is the way to test my packages in workbench. If I write a unit test then no classes are autoloaded. So this means that:
<?php
use \Mockery as m;
class ExampleTest extends TestCase {
public function tearDown()
{
m::close();
}
/**
* A basic functional test example.
*
* #return void
*/
public function testShouldReturnValidServer()
{
$mock = m::mock('MailChimp[sendCurl]');
MailChimp::listSubscribe( array( 'id' => 'c79a023ff2', 'email_address' => 'dennieriechelman#gmail.com'));
}
}
results in a error saying that class TestCase is not found. When I add class TestCase to the autoload in my composer.json (the one in my package folder) the class is available. However then I get the next error that "Illuminate\Foundation\Testing\TestCase" is not available etc. etc.
So my question is what should I autoload in my composer.json in my package folder? Everything just like in my main composer.json or is there some other way that I am missing.
I know that in the manuel it says"
You may git init from the workbench/[vendor]/[package] directory and git push your package straight from the workbench! This will allow you to conveniently develop the package in an application context without being bogged down by constant composer update commands.
However I do not understand this. Can someone explain what is meant with this? By the way I am familiar with git. I just do not get the context.
EDIT1
As far I understand now is that you push your package to your repository and then include it in your main composer.json as package. I just do not see how this is helpful when developing. Hopefully I understand this wrong.. :)
EDIT2
I was wrong. You keep your package in workbench until it stable. Just like Nils pointed out below.The question still remains though. How do I create an environment in which I can unit test with the app started. I mean like testing a model where I can mock the facades etc. Or is doing this in the workbench bad practice?
I created a package for this purpose at https://github.com/orchestral/testbench
If you don't mind merging the results of your workbench testing with the results of your main application, you can simply add extra directories to your main phpunit.xml in your laravel root like this:
<testsuites>
<testsuite name="Application Test Suite">
<directory>./app/tests/phpunit/</directory>
<directory>./workbench/vendor/packageOne/tests/</directory>
<directory>./workbench/vendor/packageTwo/tests/</directory>
</testsuite>
</testsuites>
Then in the tests folder of your package, place your phpunit tests as normal, along with the TestCase.php file, adjusting the createApplication() function to be:
<?php
class TestCase extends \Illuminate\Foundation\Testing\TestCase {
public function createApplication()
{
$unitTesting = true;
$testEnvironment = 'testing';
return require './bootstrap/start.php';
}
Make sure your package composer.json auto-loads that TestCase.php file like so:
"autoload": {
"classmap": [
"tests/phpunit/TestCase.php"
]
}
Run composer dump-autoload -o to get everything aligned and then you should be able to run phpunit from your laravel root and it will test both your application and your packages.
Extend from the proper namespace and you should be able to run tests from package dir.
class ExampleTest extends \Illuminate\Foundation\Testing\TestCase {
..
}
See also Laravels neat testing helpers in workbench?