One question in short: can phpunit use multiple data provider when running test?
For example, I have a method called getById, and I need to run both successful and unsuccessful testcases for it.
The successful testcases means that it can return a corresponding record. And for the unsuccessful, the input can fall in two categories: invalid and failed.
The invalid means that the input is not legal, while failed means the input could be valid, but there is no corresponding record with that ID.
So the code goes like this:
/**
* #dataProvider provideInvalidId
* #dataProvider provideFailedId
*/
public function testGetByIdUnsuccess($id)
{
$this->assertNull($this->model->getById($id));
}
But it turned out that only the first data provider has been used, ignoring the second one. Though I am not sure this senario is common or not, but here is the question. Can we use multiple data provider? And if we can, how?
PS: did not find too much help in here
Just an update to the question, a pull request was accepted and now the code:
/**
* #dataProvider provideInvalidId
* #dataProvider provideFailedId
*/
public function testGetByIdUnsuccess($id)
{
$this->assertNull($this->model->getById($id));
}
Will work on PHPUnit 5.7, you'll be able to add as many providers as you want.
You can use a helper function as shown below. The only problem is if the total number of test cases provided by all "sub data providers" is large, it can be tedious to figure out which test case is causing a problem.
/**
* #dataProvider allIds
*/
public function testGetByIdUnsuccess($id)
{
$this->assertNull($this->model->getById($id));
}
public function allIds()
{
return array_merge(provideInvalidId(),provideFailedId());
}
You can also use CrossDataProviders which allows you to use a combination of data providers with each other
<?php
/**
* #dataProvider provideInvalidIdAndValues
*/
public function testGetByIdUnsuccess($id, $value)
{
$this->assertNull($this->model->getById($id));
}
function provideInvalidIdAndValues() {
return DataProviders::cross(
[[1], [2], [3]],
[['Rob'], ['John'], ['Dennis']]
);
}
You can add a comment to your dataProvider array, to provide the same functionality, while not requiring multiple dataProviders.
public static function DataProvider()
{
return array(
'Invalid Id' => array(123),
'Failed Id' => array(321),
'Id Not Provided' => array(NULL),
);
}
well,you could consider it from another side ;)
you know exactly what is your expected,for example getById(1) expected result is $result_expected,not $result_null
so,you could make a dataprovider like this
$dataProvider = array(1, 'unexpected');
then,your test method like this:
public function testGetById($id) {
$this->assertEquals($result_expected, $obj::getById($id));
}
so,test result is:
.F
Related
I'm using Laravel 9 and I have a request can contains :
Parameter called SEASON the value can be an array or null
so SEASON parameter can be an array and can be also null
Parameter called EXPIRY can be an array and can be also null
I have two classes one for the SEASON feature and the other class for EXPIRY both they extends from Repository. and both have a method called execute that return an array
abstract class Repository
{
abstract public function execute(): array;
}
class Expiry extends Repository
{
public function execute()
{
return ['The Request contain Expiry Parameter, and seasonal behaviours is done'];
}
}
class Season extends Repository
{
public function execute()
{
return ['The Request contain Season Parameter, and expiry behaviours is done'];
}
}
I would like to call execute method of Season class if my request contains SEASON, or call the execute method of expiry if my request contains Expiry. OR Call both of them and merge the execute return of execute in one array so I can have as result.
['The Request contain Expiry Parameter, and seasonal behaviours is done', 'The Request contain Expiry Parameter, and expiry behaviours is done']
That's what I tried inside my controller :
public function bootstrap($data)
{
$parseTopics = Helper::parseTopicsRequest();
$basicProgram = new BasicProgramRepository();
$seasonalProgram = new SeasonalProgramRepository($parseTopics['SEASONAL']);
$object = count($parseTopics['SEASONAL']) ? $seasonalProgram : $basicProgram;
// Polymorphism
return $object->execute();
}
Question 1 :
I'm not sure if I should use this way or something like to fix my need:
$employe = new Program(new BasicProgramRepository());
Expected Result :
The expected result depends on if I have season parameter and expiry. What I want to achieve is to use different behaviours ( execute method )
if you want to achieve Polymorphism method, it will be better creating repository or something only for managing that logic.
here is sample.
class SampleRepository
{
/**
* repository instance value
*
* #var string[] | null
*/
private $sampleArray; // maybe here is SEASON or EXPIRY or null
/**
* constructor
*
* #param string[] | null $sampleArray
*/
public function __construct($sampleArray)
{
$this->sampleArray = $sampleArray;
}
/**
* execute like class interface role
*
* #return array
*/
public function execute()
{
return (!$this->sampleArray) ? [] : $this->getResult();
}
/**
* get result
*
* #return array
*/
private function getResult()
{
// maybe pattern will be better to manage another class or trait.
$pattern = [
"SEASON" => new Season(),
"EXPIRY" => new Expiry()
];
return collect($this->sampleArray)->map(function($itemKey){
$requestClass = data_get($pattern,$itemKey);
if (!$requestClass){ // here is space you don't expect class or canIt find correct class
return ["something wrong"];
}
return $requestClass->execute();
})->flatten();
}
}
and you can call like this.
$sampleRepository = new SampleRepository($sampleValue); // expect string[] or null like ["SEASON"],["SEASON","EXPIRY"],null
$result = $sampleRepository->execute(); // [string] or [string,string] or []
this approach is only what your parameter is secified value.
if your return result is almost same both of Season class and Expiry class, it will be better to manage on trait. (that is $pattern on sample code)
try some.
I read comments,so following..
For example, it prefers to be only getting result of getResult().
so, some pattern and so many logics shouldn't be written on getResult();
If you use trait, this is sample.
first, you need to create managing behaviors class.
Behavior.php
<?php
namespace App\Repositories;
class Behavior
{
use Behavior\BehaviorTrait;
// if you need to add another pattern, you can add trait here.
}
and then, you need to create Behavior directory at same level place.
you move that directory, you create trait file like this.
<?php
namespace App\Repositories\Behavior;
trait BehaviorTrait
{
public static function findAccessibleClass(string $itemKey)
{
return data_get([
"SEASON" => new Season(),
"EXPIRY" => new Expiry()
],$itemKey);
}
}
findAccessibleClass() method has responsible of finding correct class.
then, you call this method like this.
private function getResult()
{
return collect($this->sampleArray)->map(function($itemKey){
$requestClass = Behavior::findAccessibleClass($itemKey); // fix here.
if (!$requestClass){ // here is space you don't expect class or canIt find correct class
return ["something wrong"];
}
return $requestClass->execute();
})->flatten();
}
if your code is so much in getResult(), you will be better to separate code for responsible.
To create Behavior trait, getResult don't need to have responsible of behavior logic. it will be easy testing or fixable in short.
hope well.
I am writing a Product Class, the job of the Class is to take in a product id and to output the corresponding product name.
For e.g.:
$Product = new Product;
$Product->id = "ff62";
$Product->readId();
echo $Product->name;
// returns a string with at least 5 characters.
My PHPUnit test method looks like:
$Product = new Product;
$Product->id = "ff62"; // needs to be a variable
$Product->readId();
$this->assertEquals(gettype($Product->name), 'string');
However, my aim is to check for a different product ID each time instead of ff62 which may or may not exist in database.
Ideally one should be able to define the id variable during testing.
What is the best way to test for dynamic variables as such?
Faker is one way to do it, but I would hesitate to say it is the "best way."
Your requirements are:
1. Test a set of different variables.
2. Those variables may or may not exist in the database.
But you have several problems with how you have designed this test:
You are using gettype() and comparing it to string. This is a bad idea. If product 54 is "foo", and your test is returning "bar" for 54, it will pass. This is Programming by Coincidence. I.e., it works, but not on purpose.
The way you're setting this up does not really deal with the problem. While Faker can create fake data, it cannot automatically create known good and known bad data for your specific system and business cases. I would assume that you want to test known good data + expected results as well as known bad data + expected exceptions.
The proper way to structure this test is using #dataProvider and database fixtures / testing.
Here's what that would look like:
<?php
namespace Foo\Bar;
use PHPUnit\DbUnit\TestCaseTrait;
use PHPUnit\Framework\TestCase;
use \PDO;
USE \Exception;
class ProductTest extends TestCase
{
use TestCaseTrait;
// only instantiate pdo once for test clean-up/fixture load
static private $pdo = null;
// only instantiate PHPUnit_Extensions_Database_DB_IDatabaseConnection once per test
private $conn = null;
final public function getConnection()
{
if ($this->conn === null) {
if (self::$pdo == null) {
self::$pdo = new PDO($GLOBALS['DB_DSN'], $GLOBALS['DB_USER'], $GLOBALS['DB_PASSWD']);
}
$this->conn = $this->createDefaultDBConnection(self::$pdo, $GLOBALS['DB_DBNAME']);
}
return $this->conn;
}
public function getDataSet()
{
return $this->createMySQLXMLDataSet('tests/unit/testdata/sampleproductdata.xml');
}
/**
* Tests products against known good data in the database fixture.
* #param $id
* #param $expectedName
* #dataProvider providerTestProduct
*/
public function testProduct($id, $expectedName) {
$Product = new Product;
$Product->id = $id;
$Product->readId();
$this->assertSame($expectedName, $Product->name);
}
/**
* Provides data that should appear in the database.
* #return array
*/
public function providerTestProduct() {
// id , expectedName
return [ [ "ff62" , "fooproduct"]
, [ "dd83" , "barproduct"]
, [ "ls98" , "bazproduct"]
];
}
/**
* Tests products against known-bad data to ensure proper exceptions are thrown.
* #param $id
* #param $expectedName
*/
public function testProductExceptions($id, $expectedName) {
$Product = new Product;
$Product->id = $id;
$this->expectException(Exception::class);
$Product->readId();
}
/**
* Provides test data that when queried against the database should produce an error.
* #return array
*/
public function providerTestProductExceptions() {
// id , expectedName
return [ [ "badtype" , "fooproduct"] //Wrong id type
, [ "aaaa" , "barproduct"] //Does not exist
, [ null , "bazproduct"] //null is a no-no.
];
}
}
Here's a breakdown:
Use namespaces. Because it's 2018, and it's the right thing to do.
Use use to declare what classes you're using in the test.
Use TestCaseTrait to properly setup your TestCase
The private $pdo variable will hold your database connection for your class / test.
getConnection() is required. This will use the database, username, and password you have configured in your phpunit.xml file. Reference
getDataSet() goes and reads your datasource (fixture), then, truncates your database on your workstation / dev box, imports all the data from the fixture to put the database in a known state. (Be sure to backup your data before you do this. It's lossy on purpose. Never execute on production).
Next, you have two pairs of methods for the test cases: a test and a data provider.
The data provider in each case provides an ID you want to test, and the expected result. In the case of testProduct and providerTestProduct, we are providing ID that should exist in the database (as ensured by the fixture above). We can then check that Product::readId() is not only returning a string, but is actually returning the correct string.
In the second case, testProductException() and providerTestProductException(), we are intentionally sending bad values to the class to trigger exceptions, and then checking to make sure those bad values actually produces the desired behavior: failure / thrown exceptions.
You can randomise your dataset using random number generation.
$value = dechex(random_int(0, 255)).dechex(random_int(0, 255));
$Product = new Product;
$Product->id = $value;
$Product->readId();
$this->assertEquals('string', gettype($Product->name));
$this->assertEquals($value, $Product->name);
One usually puts the expected value to the left, and the actual one to the right.
I found out the best way to do this is to use Faker.
https://github.com/fzaninotto/Faker
While I was trying to test against different instances of a Product, I could definitely use Faker to randomly generate a product and test if the Product was being retrieved properly from the database.
Although majorly used in Laravel, Symfony, etc. It's quite easy to use even in custom PHP frameworks.
What can I use other than if(!empty( $product->a_funky_function() )) to check if the method is empty before calling it?
I've tried method_exists() and function_exists() and a whole plethora of conditions. I think the issue is that I need to have my $product variable there.
Please help.
A fairly common pattern is to have two methods on your class, along the lines of getField and hasField. The former returns the value, and the latter returns true or false depending whether or not the value is set (where "set" can mean not null, or not empty, or whatever else you might want it to mean).
An example:
class Foo
{
/** #var string */
private $field;
/**
* #return string
*/
public function getField()
{
return $this->field;
}
/**
* #return bool
*/
public function hasField()
{
return $this->getField() !== null;
}
}
This would then be used like:
if ($foo->hasField()) {
$field = $foo->getField();
...
}
Often, like in this example, the has... method often just delegates to the get... method internally, to save duplicating the logic. If the getter contains particularly heavy processing (e.g. a database lookup or API call), you might want to factor in ways to avoid performing it twice, but that's a bit out of scope.
You need absolutely to call it so it can compute the value which it will return, so I think there is no other way to know if it will return something not empty without calling it...
You have to call it.
$result = $product->getFunction();
if(!empty($result)) {
//your code here
}
this is laravel 5.3
when I preview the email using this:
$wantsheet_products = WantsheetProduct::orderByRaw(EmailService::WANTSHEET_PRODUCT_ORDER_SQL)->get();
View::make('email.wantsheet.email_wantsheet_to_supplier', ['wantsheet_products' => $wantsheet_products]);
the sorting is correct. that is, sorting is ['a','b','c'] the way i want it.
EDIT see note at the bottom
now when actually sending out the mails (i queue them), the sorting changed and is unsorted again, magic?! the change happens between the constructor and the build function
class WantsheetToSuppliersMail extends Mailable
{
public $wantsheet_products;
public $to_email;
/** #var WantsheetContact $wantsheetcontact*/
public $wantsheetcontact;
use Queueable, SerializesModels;
/**
* Create a new message instance.
*
* #return void
*/
public function __construct($wantsheet_products)
{
//$wantsheet_products is a standard eloquent model collection, e.g. i get it like this: WantsheetProduct::orderByRaw(self::WANTSHEET_PRODUCT_ORDER_SQL)->get()
$this->wantsheet_products = $wantsheet_products; //is ['a','b','c']
}
/**
* Build the message.
*
* #return $this
*/
public function build()
{
// $this->wantsheet_products is ['b','a','c'];
$subject = 'abc';
return $this->from('me#myapp.com')->view('email.wantsheet.email_wantsheet_to_supplier', [])->subject($subject);
}
}
EDIT contd.
Now when i do
WantsheetProduct::orderByRaw(EmailService::WANTSHEET_PRODUCT_ORDER_SQL)->get()->toArray();
it doesn't break the sorting any longer (so it works). But that is stupid, isn't it?
When your mail object is queued for delivery, it takes your Collection of Model instances, gets their ids, and stores the list of ids on the queued job. When the queued job is then processed, it takes those Model ids, and retrieves the data from the database.
The problem, however, is that the query being run to rebuild the collection doesn't care about the order of the ids. It just runs a whereIn() statement with the list of ids.
Everything worked when you converted your Collection toArray() because it also converted all your Models to arrays. So, it was no longer a Collection of Models, it was an array of arrays. There is no special serialization that takes place there, so the data went across exactly as you sent it.
The easiest way to get your order back is probably to override the restoreCollection method, so you can add in your order by clause to the restoration query. Add this method to your WantsheetToSuppliersMail class:
protected function restoreCollection($value)
{
if (! $value->class || count($value->id) === 0) {
return new EloquentCollection;
}
$model = new $value->class;
return $model->newQuery()->useWritePdo()
->whereIn($model->getKeyName(), $value->id)
->orderByRaw(EmailService::WANTSHEET_PRODUCT_ORDER_SQL)
->get();
}
This is the same as the current function, just that your custom order by has been applied to the query.
it is a known bug of laravel 5.3
basically reretrieve the objects in the build function e.g.
public function build()
{
$this->wantsheet_products = WantsheetProduct::orderByRaw(EmailService::WANTSHEET_PRODUCT_ORDER_SQL)->get();
$subject = 'abc';
return $this->from('me#myapp.com')->view('email.wantsheet.email_wantsheet_to_supplier', [])->subject($subject);
}
To stay with the same example I used here:
I now want to test the implementation of the protected methods in my child-classes.
Because I stub them in my test of the abstract class, the implementations themselves aren't tested.
But a protected-method isn't tested normally, so that's why I'd like your suggestions on how to test them after all.
Just like my other thread I'd like to solve this without refactoring my code.
Parent-class:
abstract class Order
{
public function __construct( $orderId, User $user )
{
$this->id = $this->findOrderId( $user->getId(), $orderId );
if ($this->id !== false) {
$this->setOrderData();
}
}
abstract protected function findOrderId( $userId, $orderIdToSearch );
private function setOrderData()
{
...
}
}
Child-class to test:
public class OrderTypeA extends Order
{
protected function findOrderId($userId, $orderId)
{
...
}
}
Test code:
class OrderTypeATest extends PHPUnit_Framework_TestCase
{
public function testFindOrderId() {
???
}
}
You can test protected/private methods using the reflection. Read this tutorial. There you will find, among the other solutions, the direct one:
/**
* Call protected/private method of a class.
*
* #param object &$object Instantiated object that we will run method on.
* #param string $methodName Method name to call
* #param array $parameters Array of parameters to pass into method.
*
* #return mixed Method return.
*/
public function invokeMethod(&$object, $methodName, array $parameters = array())
{
$reflection = new \ReflectionClass(get_class($object));
$method = $reflection->getMethod($methodName);
$method->setAccessible(true);
return $method->invokeArgs($object, $parameters);
}
Also, regarding the previous question of yours, where you are trying to test abstract class. The solution with phpunit mocking must work. But if you use PHP 7, you can use Anonymous classes to achieve the same result:
abstract class Order
{
protected $id;
public function __construct($orderId, $userId)
{
$this->id = $this->findOrderId($userId, $orderId);
if ($this->id !== false) {
$this->setOrderData();
}
}
abstract protected function findOrderId($userId, $orderIdToSearch);
private function setOrderData()
{
echo 'setOrderData';
}
}
$orderId = 1;
$userId = 1;
$order = new class($orderId, $userId) extends Order {
protected function findOrderId($userId, $orderIdToSearch)
{
return 1;
}
};
You will end up with the working $order object, which is ready for testing. Also it is good idea to put this code in the setUp() method of the Test Case.
If you are only get a valid $this->id when a order is found right. Do some like:
$order = new OrderTypeA($orderId, $user);
$this->assertNotEquals(false,$order->id);
Or if $orderId equals $this->id
$order = new OrderTypeA($orderId, $user);
$this->assertEquals($orderId,$order->id);
But not enough code/logic shown here to tell you more;)
Your abstraction does not make sense to me.
I understand that you have an object representing an order. You instantiate it by giving a user and an order id. However there's more than one type of order, and the difference between these types of orders is in the way you search them in the database storage? That doesn't sound right.
Your code does tell a weird story. You have this order id, and the first thing you do is search the order id. I just thought that you already HAVE the order id, so there shouldn't be a need to yet again search for it. Or maybe that method has the wrong name, and instead of findOrderId() it should be called findOrderById() - or findUserOrderById().
Also, you do work in the constructor. Searching for stuff should not be done there.
Your testing problem comes from the fact that you decided to implement different search strategies as an abstract method. You have to test a protected abstract method, which is not really easy. It makes it also hard to property test the main abstract order class because you have to provide an implementation - and this implementation sounds like it conceals a database access layer, so there can be plenty of things going wrong in the real code.
I suggest not allowing the order to search itself. Searching for orders should be done outside of the order object. That way, you'll likely implement that search as a public method, which can be normally tested. The code searching for orders will then decide whether you have a successfully found OrderTypeA, or maybe a missing MissingOrderTypeA, both extending the order class. The order objects should carry the order data, not the search logic to find them in the database.
Hint: If you have problems testing your code, it is 99,9% likely that your code is trying to do things the wrong way. This is not saying that things cannot be done that way, it is saying that you are about to produce hard to test code, that is also hard to maintain, and that it is a good idea to look for alternative strategies to implement the solution. Elegant code is always easy to test, because all the necessary methods are public in the relevant classes, and therefore can work together as intended.