I'd like to check a method with access control, e.g. a method is only granted with a specific role. Therefore, I know two ways in Symfony:
#Security annotation above the method (SensioFrameworkExtraBundle) OR
Calling authorization_checker explizit within my method
When it comes to unit tests (for my case phpspec, but I think phpunit behaviour is the almost the same in that case), I would like to test that only anonymous users should be able to call a method. With number 2. , it's working fine. Here my setup:
RegistrationHandlerSpec:
class RegistrationHandlerSpec extends ObjectBehavior
{
function let(Container $container, AuthorizationCheckerInterface $auth) {
$container->get('security.authorization_checker')->willReturn($auth);
$this->setContainer($container);
}
function it_should_block_authenticated_users(AuthorizationCheckerInterface $auth)
{
$auth->isGranted("ROLE_USER")->willReturn(true);
$this->shouldThrow('Symfony\Component\Security\Core\Exception\AccessDeniedException')->during('process', array());
}
}
And within the RegistrationHandler, I have the following method:
class RegistrationHandler
{
public function process()
{
$authorizationChecker = $this->get('security.authorization_checker');
if ($authorizationChecker->isGranted('ROLE_USER')) {
throw new AccessDeniedException();
}
// ...
}
}
Well, this approach is working fine - BUT normally, I would prefer using 1. with Security annotation (Sensio FrameworkExtraBundle), and therefore, it's not working / I don't know why no Exception gets triggered when it's written as an annotation:
/**
* #Security("!has_role('ROLE_USER')")
*/
public function process()
{
// ...
}
Does anyone know how to get this example to work by using the first approach with #Security annotation, which is way more readable and best practice recommended of symfony?
In both cases you're testing a behaviour that's provided by third party code (the Symfony framework). Following the rule don't mock what you don't own, rather than writing a unit test you should write an integration test. Otherwise you'll be only making assumptions on how the code works with no proof it really works this way.
In your case your integration test could be a controller test. You'd call the URL with a web test client (provided by the WebTestCase) and verify that in certain conditions you're getting a 401 or 403 response.
PHPSpec is a unit testing tool (a.k.a. a design tool). You need to write integration tests with something else (for example PHPUnit). I usually have at least three testing tools installed in my project:
PhpSpec for unit testing
PHPUnit for integration testing
Behat for acceptance testing (a form of integration testing)
Related
I've started working with Behat for behavioural testing.
I managed to set behat up for my Symfony2 project, started writing scenarios. I was happy with Behat giving me method stubs with regexp to fill in that'd correspond to the steps in my scenarios.
However, after a while, Behat stopped generating regular expressions and is giving me stub methods like this:
/**
* #Given I am on the page :arg1 <-- this is what I get
*/
public function iAmOnThePage($arg1)
{
throw new PendingException();
}
I'd rather have it work like befor, e.g.:
/**
* #Given /^I open "([^"]*)"$/ <--- I'd expect this
*/
public function iOpen($arg1, $sessionName=null)
{
$this->getSession($sessionName)->visit($arg1);
}
I must have messed somtehing up as I went, but have no idea why the default behaviour changes all of a sudden.
Any suggestions?
Did you update your version of Behat ?
In version 3 it's with the :arg and in v2.5 it's with the regex expressions.
If you like the old way of working you can follow the manual .
Implementing the SnippetAcceptingContext interface tells Behat that
your context is expecting snippets to be generated inside it. Behat
will generate simple pattern snippets for you, but if regular
expressions are your thing, Behat can generate them instead if you
implement Behat\Behat\Context\CustomSnippetAcceptingContext interface
instead and add getAcceptedSnippetType() method returning string
"regex":
public static function getAcceptedSnippetType()
{
return 'regex';
}
I'm trying to do tdd with my WordPress plugins. The problem is that using WP_UnitTestCase is way way to slow and despite the name provides integration tests rather than unit tests. So instead of using WP_UnitTestCase I have been working on creating truly isolated tests for my plugins but the problem is that I find myself using a lot of WordPress global functions such as wp_get_current_user() or wp_signon().
Currently I have a file of the functions I've used that are basically stubbed out.
What is the best way to go about mocking these functions? Ultimately I'd like to be able to mock these functions the same way as I would other methods with the ability to control their output and test that they're called. Is there a more OO way to set the current user or check for authentication that I'm missing?
You can create a class for invoking global WordPress functions. This can have a map of methods to global functions or even invoking whatever method is called that starts with wp_ using __call or any other way you come up with.
Then you would use this class from inside your plugin to call the functions. I suppose plugins are instantiated by WordPress so you won't be able to inject this class on production code. So you can make it externally settable to allow injecting a mock but if none is provided, use the real one.
Like this:
<?php
class Plugin
{
private $invoker;
public function getWpInvoker()
{
if (!isset($this->invoker)) {
$this->invoker = new WordPressGlobalFunctionsInvoker();
}
}
public function setWpInvoker(WordPressGlobalFunctionsInvoker $invoker)
{
$this->wp_invoker = $invoker;
}
public function foo()
{
$current_user = $this->getWpInvoker()->wp_get_current_user();
}
}
In the test you would mock the WordPressGlobalFunctionsInvoker class and inject the mock to the plugin so you take control over the functions being called.
Using https://insight.sensiolabs.com to scan / check my code, I get the following warning:
The Doctrine Entity Manager should not be passed as an argument.
Why is it such a bad practice to inject the Entity Manager in a service? What is a solution?
With respect to the comment that repositories cannot persist entities.
class MyRepository extends EntityRepository
{
public function persist($entity) { return $this->_em->persist($entity); }
public function flush () { return $this->_em->flush (); }
I like to make my repositories follow more or less a "standard" repository interface. So I do:
interface NyRepositoryInterface
[
function save($entity);
function commit();
}
class MyRepository extends EntityRepository implements MyRepositoryInterface
{
public function save ($entity) { return $this->_em->persist($entity); }
public function commit() { return $this->_em->flush (); }
This allows me to define and inject non-doctrine repositories.
You might object to having to add these helper functions to every repository. But I find that a bit of copy/paste is worth it. Traits might help here as well.
The idea is move away from the whole concept of an entity manager.
I am working on a quite a large project currently and have recently started following the approach with repositories that can mutate data. I don't really understand the motivation behind having to inject EntityManager as a dependency which is as bad as injecting ServiceManager to any class. It is just a bad design that people try to justify. Such operations like persist, remove and flush can be abstracted into sth like AbstractMutableRepository that every other repository can inherit from. So far it has been doing quite well and makes code more readable and easier to unit test!
Show me at least one example of a service that has EM injected and unit test for it looked correctly? To be able to unit test sth that has EM injected is more about testing implementation than anything else. What happens is then you end up having so many mocks set up for it, you cannot really call it a decent unit test! It is a code coverage hitter, nothing more!
I need it in FlexUnit to test private methods. Is there any possibility to do this via reflection by using describeType or maybe flexUnit has some build in facility? I dislike artificial limitation that i cannot test private functions, it greatly reduces flexibility. Yes it is good design for me to test private functions, so please do not advise me to refactor my code. I do not want to break the encapsulation for the sake of unit testing.
I'm 99% certain this isn't possible and I'm intrigued to know why you would want to do this.
You should be unit testing the output of a given class, based on given inputs, regardless of what happens inside the class. You really want to allow someone to be able to change the implementation details so long as it doesn't change the expected outputs (defined by the unit test).
If you test private methods, any changes to the class are going to be tightly coupled to the unit tests. if someone wants to reshuffle the code to improve readability, or make some updates to improve performance, they are going to have to update the unit tests even though the class is still functioning as it was originally designed.
I'm sure there are edge cases where testing private methods might be beneficial but I'd expect in the majority of cases it's just not needed. You don't have to break the encapsulation, just test that your method calls give correct outputs... no matter what the code does internally.
Just create a public method called "unitTest" and call all your unit tests within that method. Throw an error when one of them fails and call it from your test framework:
try {
myobject.unitTest();
} catch (Exception e) {
//etc.
}
You cannot use describeType for that.
From the Livedocs - flash.utils package:
[...]
Note: describeType() only shows public properties and methods, and will not show
properties and methods that are private, package internal or in custom namespaces.
[...]
When the urge to test a private method is irresistible I just create a testable namespace for the method.
Declare a namespace in a file like this:
package be.xeno.namespaces
{
public namespace testable = "http://www.xeno.be/2015/testable";
}
Then you can use the testable as a custom access modifier for the method you want to test like this:
public class Thing1
{
use namespace testable;
public function Thing1()
{
}
testable function testMe() : void
{
}
}
You can then access that modifier by using the namespace in your tests:
public class Thing2
{
use namespace testable;
public function Thing2()
{
var otherThing : Thing1 = new Thing1();
otherThing.testMe();
}
}
Really though I think this is a hint that you should be splitting your functionality into a separate class.
I'm setting up a functional test suite for an application that loads an external configuration file. Right now, I'm using flexunit's addAsync function to load it and then again to test if the contents point to services that exist and can be accessed.
The trouble with this is that having this kind of two (or more) stage method means that I'm running all of my tests in the context of one test with dozens of asserts, which seems like a kind of degenerate way to use the framework, and makes bugs harder to find. Is there a way to have something like an asynchronous setup? Is there another testing framework that handles this better?
It is pretty easy, but took me 2 days to figure it out.
The solution:
First you need to create a static var somewhere.
public static var stage:Stage
There is a FlexUnitApplication.as created by the flexunit framework, and at the onCreationComplete() function, you can set the stage to the static reference created previously:
private function onCreationComplete():void
{
var testRunner:FlexUnitTestRunnerUIAS=new FlexUnitTestRunnerUIAS();
testRunner.portNumber=8765;
this.addChild(testRunner);
testStageRef.stage=stage //***this is what I've added
testRunner.runWithFlexUnit4Runner(currentRunTestSuite(), "testsuitename");
}
and when you would access the stage in the program, you should replace it to:
if(stage==null) stage=testStageRef.stage
Assuming you're using FlexUnit 4, addAsync can be called from a [BeforeClass] method:
public class TestFixture
{
[BeforeClass]
public static function fixtureSetup() : void
{
// This static method will be called once for all the tests
// You can also use addAsync in here if your setup is asynchronous
// Any shared state should be stored in static members
}
[Test]
public function particular_value_is_configured() : void
{
// Shared state can be accessed from any test
Assert.assertEquals(staticMember.particularValue, "value");
}
}
Having said that, testing code that accesses a file is really an integration test. I'm also hardly in a position to argue against using ASMock :)
Sounds like you need to remove the dependency of loading that external file. Pretty much all Aysnchronous tests can be removed through the use of a mocking frameworks. ASMock is an awesome choice for Flex. It will allow you to fake the URLoader object and return faked configurations to run your tests against. Mocking will help with you write much better unit tests as you can mock all dependencies synchronous or asynchronous.