PhpUnit::How can be __construct with protected variables tested?
(not always we should add public method getVal()- soo without add method that return protected variable value)
Example:
class Example{
protected $_val=null;
function __construct($val){
$this->_val=md5 ($val);
}
}
Edit:
also exist problem to test in function that return void
Edit2:
Example why we need test __construct:
class Example{
protected $_val=null;
//user write _constract instead __construct
function _constract($val){
$this->_val=md5 ($val);
}
function getLen($value){
return strlen($value);
}
}
class ExampleTest extends PHPUnit_Framework_TestCase{
test_getLen(){
$ob=new Example();//call to __construct and not to _constract
$this->assertEquals( $ob->getLen('1234'), 4);
}
}
test run ok, but Example class "constructor" wasn't created!
Thanks
The main goal of unit testing is to test interface By default, you should test only public methods and their behaviour. If it's ok, then your class is OK for external using. But sometimes you need to test protected/private members - then you can use Reflection and setAccessible() method
Create a derived class that exposes the value that you want to test.
Related
Is there a way to unit-test protected or private methods of a class? As it is now, I'm making a lot of methods public in order to be able to test them, which breaks the API.
Edit: Actually answered here: Best practices to test protected methods with PHPUnit
You can access your private and/or protected method by using the ReflectionMethod class followed by invoke method, but to invoke the method you also need an instance of your class which in certain situations isn't possible. Based on this one nice example that works is this one:
Get a mock of your class:
$mockedInstance = $this->getMockBuilder(YourClass::class)
->disableOriginalConstructor() // you may need the constructor on integration tests only
->getMock();
Get your method to be tested:
$reflectedMethod = new \ReflectionMethod(
YourClass::class,
'yourMethod'
);
$reflectedMethod->setAccessible(true);
Call your private/protected method:
$reflectedMethod->invokeArgs( //use invoke method if you don't have parameters on your method
$mockedInstance,
[$param1, ..., $paramN]
);
For protected methods, you can subclass the class under test:
class Foo
{
protected function doThings($foo)
{
//...
}
}
class _Foo extends Foo
{
public function _doThings($foo)
{
return $this->doThings($foo);
}
}
and in the test:
$sut = new _Foo();
$this->assertEquals($expected, $sut->_doThings($stuff));
With private methods it is a bit more difficult, you could use the Reflection API to call protected methods. Also, there is an argument that private methods should only come into existence during refactoring so should be covered by the public methods that call them, but that only really works if you did test-first to start with and in real life we have legacy code to deal with ;)
Links for the reflection api:
http://php.net/manual/en/reflectionmethod.setaccessible.php
Also, this link looks useful for this purpose:
https://jtreminio.com/2013/03/unit-testing-tutorial-part-3-testing-protected-private-methods-coverage-reports-and-crap/
I have model class that calls mailer class inside one of its methods:
class someModel{
public function sendEmail($data){
$mailer = new Mailer();
$mailer->setFrom($data['from']);
$mailer->setTo($data['to']);
$mailer->setSubject($data['subject']);
return $mailer->send();
}
}
How can I test sendEmail method? Maybe I should mock mailer class and check if all these mailer methods were called in sendMail method?
Your help would be appreciated.
IMO wrapping the Mailer class does not solve the problem you're facing, which is you don't have control over the Mail instance being used.
The problem comes from creating the dependencies inside the object that needs them instead of injecting them externally like this:
class someModel{
private $mailer;
public function __construct(Mailer $mailer) {
$this->mailer = $mailer;
}
public function sendEmail($data){
$this->mailer->setFrom($data['from']);
$this->mailer->setTo($data['to']);
$this->mailer->setSubject($data['subject']);
return $this->mailer->send();
}
}
When creating the someModel instance, you must pass a Mail instance (which is an external dependency). And in the test you can pass a Mail mock that will check that the correct calls are being made.
Alternative:
If you feel that injecting a Mail instance is bad (maybe because there are lots of someModel instances), or you just can't change your code this way, then you could use a Services repository, that will keep a single Mail instance and that allows you to set it externally (again, in the test you would set a mock).
Try a simple one like Pimple.
I would (and have in my own code with Mailer!) wrap your instance of Mailer inside a class that you write. In other words, make your own Email class that uses Mailer under the hood. That allows you to simplify the interface of Mailer down to just what you need and more easily mock it. It also gives you the ability to replace Mailer seamlessly at a later date.
The most important thing to keep in mind when you wrap classes to hide external dependencies is keep the wrapper class simple. It's only purpose is to let you swap out the Email libraries class, not provide any complicated logic.
Example:
class Emailer {
private $mailer = new Mailer();
public function send($to, $from, $subject, $data) {
$this->mailer->setFrom($from);
$this->mailer->setTo($to);
...
return $mailer->send();
}
}
class EmailerMock extends Emailer {
public function send($to, $from, $subject, $data) {
... Store whatever test data you want to verify ...
}
//Accessors for testing the right data was sent in your unit test
public function getTo() { ... }
...
}
I follow the same pattern for all classes/libraries that want to touch things external to my software. Other good candidates are database connections, web services connections, cache connections, etc.
EDIT:
gontrollez raised a good point in his answer about dependency injection. I failed to explicitly mention it, but after creating the wrapper the way you would want to use some form of dependency injection to get it into the code where you want to use it. Passing in the instance makes it possible to setup the test case with a Mocked instance.
One method of doing this is passing in the instance to the constructor as gontrollez recommends. There are a lot of cases where that is the best way to do it. However, for "external services" that I am mocking I found that method became tedious because so many classes ended up needing the instance passed in. Consider for example a database driver that you want to Mock for your tests, but you use in many many different classes. So instead what I do is create a singleton class with a method that lets me mock the whole thing at once. Any client code can then just use the singleton to get access to a service without knowing that it was mocked. It looked something like this:
class Externals {
static private $instance = null;
private $db = null;
private $email = null;
...
private function __construct() {
$this->db = new RealDB();
$this->mail = new RealMail();
}
static function initTest() {
self::get(); //Ensure instance created
$db = new MockDB();
$email = new MockEmail();
}
static function get() {
if(!self::$instance)
self::$instance = new Externals();
return self::$instance;
}
function getDB() { return $this->db; }
function getMail() { return $this->mail; }
....
}
Then you can use phpunit's bootstrap file feature to call Externals::initTest() and all your tests will be setup with the mocked externals!
First, as RyanW says, you should write your own wrapper for Mailer.
Second, to test it, use a mock:
<?php
class someModelTest extends \PHPUnit_Framework_TestCase
{
public function testSendEmail()
{
// Mock the class so we can verify that the methods are called
$model = $this->getMock('someModel', array('setFrom', 'setTo', 'setSubject', 'send'));
$controller->expects($this->once())
->method('setFrom');
$controller->expects($this->once())
->method('setTo');
$controller->expects($this->once())
->method('setSubject');
$controller->expects($this->once())
->method('send');
$model->sendEmail();
}
}
The above code is untested, but it basically mocks the someModel class, creating dummy functions for each each function called within sendEmail. It then tests to make sure each of the functions called by sendEmail is called exactly once when sendEmail is called.
See the PHPUnit docs for more info on mocking.
I am curious to know it is good practice to create object in test class __construct or we should always use setup/teardown approach ( or setUpBeforeClass/tearDownAfterClass approach)?
I aware of the fact set/teardown gets called for each test so will it do any good if I put my object creation code in it? e.g.
//mytestclass.php
class MyTestClass extends PHPUnit_Framework_TestCase
{
private $obj;
protected function setUp()
{
$this->obj = new FooClass();
}
public testFooObj()
{
//assertions for $this->obj
}
...
}
what could be the issues if I create object in constructor like this:
class MyTestClass extends PHPUnit_Framework_TestCase
{
private $obj;
protected function __construct()
{
$this->obj = new FooClass();
}
public testFooObj()
{
//assertions for $this->obj
}
...
}
I tried googling around as well as PHPUnit documentation couldn't get much information about, Can you please help me to understand which one is good practice?
setUp() gets called before each of your tests is ran. __construct() happens when your class is instantiated. So if you have multiple tests and they use local properties and modify them, using setUp() you can ensure that they are the same before each test is ran. The opposite of setUp() is tearDown() where you can ensure that test data gets cleaned up after each test.
As I have just found out, implementing the default class constructor instead of the setupBeforeClass() method breaks the #dataProvider annotations (probably all kinds of annotations), yielding a "Missing argument" exception for any parameterized tests.
Missing argument 1 for AppBundle\Tests\Service\InvitationVerifierTest::testDireccionInvalida()
Replacing public function __construct() for public static function setUpBeforeClass() gets rid of the exception. So there it goes, favor the setupBeforeClass() method over the regular constructor.
PHPUnit version 4.5.0
I'm trying to test my eloquent models but my tests keep failing with "Class 'Eloquent' not found" errors. If I add a route that uses my eloquent model and simply prints some of the information stored in the database, everything works fine. It is only when trying to run phpunit that I get the issues with eloquent not being found. My model is in app/models so it should be included in the composer classmap and I've done composer dump-autoload. I'm sure I'm overlooking something really obvious but I can't pick it out. Any idea what the issue is?
My test:
class GameTest extends TestCase {
public function setUp(){
$this->game = Game::find(1);
}
public function testGameInstance(){
$this->assertInstanceOf('Game', $this->game);
}
}
My model:
class Game extends Eloquent{
protected $table = 'gm_game';
protected $primaryKey = 'game_id';
}
Try adding parent::setUp() in your test's setUp function. This solved the issue for me.
Example:
class GameTest extends TestCase {
public function setUp(){
parent::SetUp();
$this->game = Game::find(1);
}
public function testGameInstance(){
$this->assertInstanceOf('Game', $this->game);
}
}
This question is posed from an ActionScript context but could be from a Java one equally.
The code I am using as a sample comes from adobe.com/devnet/flex/articles/flex4_skinning.html. In the code extract below the NoteCard class has an enabled and a disabled state which it inherits from the SkinnableComponent class. My question is; why in the enabled setter do we call super.enabled = value; and not this.enabled = value;. We have created our NoteCard object instance from the constructor and should we not then be able to set the value of the enabled member using the "this" keyword. If you do swap super for this no errors are shown by the compiler but the code fails to work.
package
{
import spark.components.supportClasses.SkinnableComponent;
public class NoteCard extends SkinnableComponent
{
public function NoteCard()
{
super();
}
override public function set enabled(value:Boolean) : void
{
if (enabled != value)
invalidateSkinState();
super.enabled = value;
}
override protected function getCurrentSkinState() : String
{
if (!enabled)
return "disabled";
return "normal"
}
}
}
If we'll use:
override public function set enabled(value:Boolean) : void
{
if (enabled != value)
invalidateSkinState();
enabled = value;
}
We'll run into infinite loop. This line:
enabled = value;
will call the same setter again and again.
In this special case you override a setter for a class. You can implement your own additional code to handle the newly set value, but the code from your superclass should also be called, because you may not know, what the base class setter will do (may be set a private variable with a value). You have to call super.setterName = value to assure this. If you would call with this you would call your implemented setter in an infinite loop. You may omit the super call, if you are sure, this isn't necessary.