I have a couple of tests in my test suite being run in Zend_Test
One test creates a mock of Foo_Bar_Baz via PHPUnit's MockBuilder as that class its dependency. Now in the test for Foo_BAR_baz (the change in case is on purpose and is necessary due to autoloading), I am not getting the class but rather an instance of the mock, which obviously doesn't work.
Doing a var_dump on the object results in class Foo_Bar_Baz#27115(0) { } so it appears to be creating an instance of the mock.
Fixing the case of in the mock gets things to work as expected. I have never seen this behavior in mocking objects before. For some reason the mocked class is being loaded into PHP so that when the next test tries to instantiate the real object it instantiates the mock instead. Why would this be happening?
Class names in PHP are not case-sensitive, but filenames on a *nix server are.
I suspect the change in case is causing a change in behaviour because of an autoload mechanism; PHP would only autoload one of Foo_Bar_Baz.php and Foo_BAR_Baz.php.
In your case, if you have already defined a class Foo_BAR_Baz (as a mock) then PHP will use the same definition for Foo_Bar_Baz, thereby ignoring your real class definition.
Related
I use this at the top of my class, that I run a test against:
use TYPO3\CMS\Core\Utility\ExtensionManagementUtility;
require_once ExtensionManagementUtility::siteRelPath('my_ext') . 'Lib/ServiceLoader.php';
class Tx_MyOtherExt_Domain_Service_SearchService implements SingletonInterface
Then in my test I get an instance of that class, like this:
/** #var \Tx_MyOtherExt_Domain_Service_SearchService $service */
$service = GeneralUtility::makeInstance('\Tx_MyOtherExt_Domain_Service_SearchService');
However, the test throws an error:
Fatal error: main(): Failed opening required 'typo3conf/ext/my_ext/Lib/ServiceLoader.php' (include_path='C:/xampp/htdocs/my_proj/site/typo3/contrib/pear/;.;C:\xampp\php\PEAR')
How can I add the site root to the include path? The PHPSTORM settings (Settings->PHP) don't seem to make a difference.
NOTE: adding the site root to the include_path setting in php.ini works, of course. But as this path changes per project, setting this via PHPSTORM would be best.
How about using the constant PATH_site to get an absolute path?
https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/GlobalValues/Constants/Index.html
There are several things you should improve writing your code. First of all, it is also about changing the running code.
Use injection
If you need a separate class in your code, use e.g. constructor injection to inject the object into a property. By calling $this->getAccessibleMock with the 5th argument to false the original constructor won't call and you can fake the object by using `->_set('name', $obj)``
GeneralUtility::makeInstance
Don't use that in the tests but new(). If the tests breaks, your code is wrong and should be changed instead of building the test's code around it!
I have a spring-mvc application that is using java configuration, not xml. There are #Configuration annotations sprinkled through several files. In particular, there is a #PropertySources annotation in one file in a class that implements WebMvcConfigurerAdapter. There are two classes which contain an #Autowired Environment variable. One of these classes is itself a #Configuration class, and I would like it to have access to the fully-loaded Environment at the time it runs.
This isn't happening. When this code executes, the Environment is still null. I've tried reordering the #ComponentScan packages, tried moving the #PropertySources annotation, and nothing has helped me load the property sources in time.
I want this to happen first, before any other configuration.
What must I do to make it so?
UPDATE: After trying many things, including the Order annotation, I find the problem seems to be not so much that the #PropertySources are being loaded too late as that a class I have that is derived from org.springframework.security.web.context.AbstractSecurityWebApplicationInitializer is being loaded too soon. Nothing in my code even references this class but Spring is somehow deciding that this, above all other classes, must be initialized first. No amount of messing around with #Order seems to change this. This in spite of the javadocs, which indicate that the behavior I want is the default:
Caveats
Subclasses of AbstractDispatcherServletInitializer will register their
filters before any other Filter. This means that you will typically
want to ensure subclasses of AbstractDispatcherServletInitializer are
invoked first. This can be done by ensuring the Order or Ordered of
AbstractDispatcherServletInitializer are sooner than subclasses of
AbstractSecurityWebApplicationInitializer.
You can use ContextInitializer, catch the moment when Boot prepared its environment and "inject" your property source programmatically as you want.
If you have a ConfigurableApplicationContext then it provides a ConfigurableEnvironment, which contains the propertySources as a list. If you want your PropertySource to rule all above the others than add it as first. If you want to place it to a special position then you can add it before an other, identified by its "name".
public class ConfigInitializer implements ApplicationContextInitializer<ConfigurableApplicationContext> {
#Override
public void initialize(ConfigurableApplicationContext ctx) {
// rule over all the others:
ctx.getEnvironment().getPropertySources().
addFirst(new ResourcePropertySource("file:/etc/conf/your_custom.properties"));
// rule over application.properties but not argument or systemproperties etc
ctx.getEnvironment().getPropertySources().
addBefore("applicationConfig: [classpath:/application.properties]",
new ResourcePropertySource("classpath:your_custom.properties"));
// names can be discovered by placing a breakpoint somewhere here and watch
// ctx.getEnvironment().getPropertySources().propertySourceList members,
// each has a name ...
}
}
You can bring into play this class by:
registering it in the application.properties :
context.initializer.classes=a.b.c.ConfigInitializer
or from application start :
new SpringApplicationBuilder(YourApplication.class).
initializers(new ConfigInitializer()).
run(args);
By the way this is a proper way to inject more of your custom properties, like properties coming from a database or a different host etc...
Not that I am an expert in Java config but maybe:
Spring 4 utilizes this feature in its #PropertySource annotation. To
remind you, #PropertySource annotation provides a mechanism for adding
a source of name/value property pairs to Spring's Environment and it
is used in conjunction with #Configuration classes.
Taken from: http://blog.codeleak.pl/2013/11/how-to-propertysource-annotations-in.html
Are you using #PropertySource or #PropertySources?
Have You tried 'order' property for spring bean initialisation?
I'm running into an interesting issue when using OCMock 3 when partially mocking an object that defines class methods. I'm not sure if this is an issue with the dynamic subclassing that takes part as partial mocking or my misunderstanding of the objc runtime. Any help would be greatly appreciated.
As part of running tests and other debug builds we do some runtime verification of method declarations using OmniFoundations' OBRuntimeCheck. One of these checks, in short, attempts to use the runtime to verify that type signatures match for class methods across inheritance and protocol conformance. This happens by listing the classes registered in the runtime and for each class the instance methods of the metaClass are copied. For each Method from the metaClass if it exists on the metaClass's superclass the type signatures are compared.
The problem comes when calling class_getInstanceMethod on the metaClass's superclass for one of the ocmock replacement selectors, ocmock_replaced_*. The test crashes EXC_BAD_INSTRUCTION code=EXC_i386_INVOP subcode=0x0 and no class for metaclass is logged in the console. Example given:
class_getInstanceMethod(metaSuperClass, NSSelectorFromString(#"ocmock_replaced_classMessage"))
When partial mocking an object that defines a class method, it appears that the OCMock 3 framework generates a dynamic subclass, does some isa swizzling of the mocked object and also some isa swizzling of the dynamically generated class' metaClass.
This behavior and crash is new in OCMock 3 and I'm really at a loss of where to look next. Any runtime gurus have any idea what may be going on here? When looking through the code it did surprise me that the dynamically generated class used for the mock was having it's meta class swizzled out, but I don't necessarily think that is wrong. For ease in debugging I have created a simplified test case in a fresh fork of OCMock. The crashing test can be found here. Any help for guidance would be greatly appreciated.
I may be way off here, but I thought the superclass of a metaClass is NSObject (which is why you can normally call NSObject instance methods on class objects). I'm not sure you should be doing anything, normally, with the superclass of a metaClass.
In general, the metaClass stores all of the information about class methods. Therefore, getting an "instance" method on a metaClass is the same as getting a class method on the associated regular Class. The runtime can simply dereference the "isa" pointer of an instance to find a method list to find instance methods; doing the same on a Class object gets the meta class (of the same structure) and therefore the same process results in finding the class methods.
OCMock will create a magic subclass for any partial mock, and change the class on that instance to the new subclass, so all the instance method swizzling will be specific to that instance. For class methods though, I thought it had to modify the original class itself -- otherwise, calls to the regular class method in regular code would not be intercepted. It keeps a copy of the original implementation so that when you call -stopMocking on the mock it can restore the original implementation (the added ocmock_replaced* impl will still be there but should no longer be called).
You could simply ignore any selector which starts with "ocmock_replaced" since that really is not related to your actual code you are presumably checking. You might also have better luck changing "class_getInstanceMethod(metaSuperClass, ..." to "class_getClassMethod(regularSuperClass, ..."). I'm not sure why you would be getting a crash though -- I would expect class_getInstanceMethod(metaSuperClass, ...) to just return NULL in most situations.
I am trying to find the easy way to load my fixtures in Symfony 2.6 to run functional tests. This is a quite common question, and has been asked a few times, but the answers I have found so far do not quite reach my expectations:
Some rely on running the command line from inside the functional test.
Other run manually each one of the defined fixtures, and then take care of creating and deleting the database.
There is a lot of overhead in both cases (use statements and manual code), for a task that I believe is very standard.
On the other hand, these same posts recommend the LiipFunctionalTestBundle. Going for it, here is what I read in the installation instructions:
write fixture classes and call loadFixtures() method from the bundled
Test\WebTestCase class. Please note that loadFixtures() will delete the contents from the database before loading the fixtures."
So I tried...
namespace AppBundle\Test\Controller;
use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;
class MyControllerTest extends WebTestCase
{
public function setUp()
{
$classes = array(
'AppBundle\DataFixtures\LoadUserData',
);
$this->loadFixtures($classes);
}
...
}
With no luck:
Call to undefined method AppBundle\Tests\Controller\MyControllerTest::loadFixtures() in /gitrepos/myproject/src/AppBundle/Tests/Controller/MyControllerTest.php on line 15
a static call gives the same error...
self:loadFixtures($classes);
I really think I am missing something pretty obvious. Anyone can get me back on track ?
I can see you're using
Oro\Bundle\TestFrameworkBundle\Test\WebTestCase
as the base class while I think you should use
Liip\FunctionalTestBundle\Test\WebTestCase
to be able to call this method.
I would like my test to fail if I mock an interface using Mockery and use a shouldReceive with a non-existing method. Looking around didn't help.
For instance :
With an interface :
interface AInterface {
public function foo();
public function bar();
}
And a test case :
function testWhatever{
Mockery::mock('AInterface')->shouldReceive('bar');
$this->assertTrue(true);
}
The test will pass.
Now, refactoring time, bar method is not needed in one place (let's say it's needed on several places) and is suppressed from the interface definition but the test will still pass. I would like it to fail.
Is it possible to do such a thing using mockery (and to be able to do the same thing with a class instead of an interface) ?
Or does a workaround exist with some other tool or a testing methodology ?
Not sur if this can be understood as is, will try to make a clearer description of the issue if needed.
To ensure that Mockery doesn't allow you to mock methods that don't exist, put the following code in your PHPUnit bootstrap file (if you want this behavior for all tests):
\Mockery::getConfiguration()->allowMockingNonExistentMethods(false);
If you just want this behavior for a specific test case, put the code in the setUp() method for that test case.
Check this section of the Mockery manual on Github for more information.
If you want to make sure that the method is called only one time, you can use once().
Suppose that the class AImplementation, implements the interface AInterface, and you wanna tested that the method is called, an example could be:
Mockery::mock('AImplementation')->shouldReceive('bar')->once();
You can also use: zeroOrMoreTimes(), twice() or times(n), checkout the repo at github. Also, I recommend you this tutorial by Jeffrey W