Looking at the following code, I see the constructor is returning a value. I thought that constructors only return objects. Can someone tell me what am I missing?
public function __construct($username = null, $password = null){
$urlLogin = "{$this->apiHost}/login/$username";
$postData = sprintf("api_type=json&user=%s&passwd=%s",
$username,
$password);
$response = $this->runCurl($urlLogin, $postData);
if (count($response->json->errors) > 0){
return "login error";
} else {
$this->modHash = $response->json->data->modhash;
$this->session = $response->json->data->cookie;
return $this->modHash;
}
}
Indeed you are correct. Nothing can be done with the return value of a constructor (aside from using the Object it created).
So no, you aren't missing anything, it's the developer who wrote that code who is.
It is technically possible to use return values from constructors, if you call the function directly
$obj->__construct();
That would allow you to use the constructor's return value. However, that is highly uncommon and fairly not recommended.
You can do whatever you want with the return value of a constructor, so it's not true that "Nothing can be done with the return value of a constructor (aside from using the Object it created)." The return value of a constructor is not the object "it" created. The constructor does not create objects (the new keyword does). The return value of a constructor is the same as that of any other function: whatever you choose to return. Further, it is also false that an object already has to exist in order to call its constructor. This is perfectly valid:
$parent_constructor_return_value = parent::__construct();
For example:
abstract class MyBase {
function __construct () {
return "Hello, world.";
}
}
class MyDerived extends MyBase {
function __construct () {
echo parent::__construct();
}
}
new MyDerived(); // prints "Hello, world."
While this is possible, I can't conceive of a scenario in which it would be best practice. After all, you could always call a method other than parent::__construct() to get your value, and all you lose is obscurity. I suppose it could be used as a way of error-handling--there are two other ways to accomplish the same thing:
Throw Exceptions in the parent constructor and catch them in your derived constructor.
Set properties in the parent constructor indicating that an error happened, and then check the state of those properties in the derived constructor.
If an error in a parent constructor is not exceptional, he might have decided to have the parent constructor return error values, rather than storing transient error information as object properties. Of course, then the only reason to name the parent's method __construct is if the parent class is not abstract but can itself be instantiated--but in that context, the returned error messages would never be seen. So, bad pattern; bad. Constructors are not intended to return values, which means you're opening an architectural can of worms by leveraging this mechanism.
A constructor returns nothing, but you can return from it (stopping the method execution at a point for some reason but the object can be created).
See this page: Returning a value in constructor function of a class
Read it:-
Constructors don't get return values; they serve entirely to instantiate the class.
Without restructuring what you are already doing, you may consider using an exception here.
public function __construct ($identifier = NULL)
{
$this->emailAddress = $identifier;
$this->loadUser();
}
private function loadUser ()
{
// try to load the user
if (/* not able to load user */) {
throw new Exception('Unable to load user using identifier: ' . $this->identifier);
}
}
Now, you can create a new user in this fashion.
try {
$user = new User('user#example.com');
} catch (Exception $e) {
// unable to create the user using that id, handle the exception
}
If you're always expecting a string as a return value you can add the method __toString() then if you try to print that class it will return what you placed in there, only strings, and i can see that it's your case here, so i believe that should work for you..
public function __construct($username = null, $password = null){
$urlLogin = "{$this->apiHost}/login/$username";
$postData = sprintf("api_type=json&user=%s&passwd=%s",
$username,
$password);
$response = $this->runCurl($urlLogin, $postData);
if (count($response->json->errors) > 0){
return "login error";
} else {
$this->modHash = $response->json->data->modhash;
$this->session = $response->json->data->cookie;
return $this->modHash;
}
}
public function __toString(){
return $this->modeHash;
}
...
echo yourClass($username, $password); // will return yourClass->modeHash;
Unlike in other languages, in PHP you can explicitly call the constructor. It's just another function. It looks like the original author first decided to put some code that could fail in the constructor, then realized that he needs a way to rerun the initialization after a failure.
$result = $user->__construct($username, $password)
would actually work and you do get the return value. It's an ugly way to do things obviously.
In my opinion, it's not a good practice to have code that trigger side effects in the constructor. I would put the code in a separate function, with a name that clearly states what it does.
Related
I am testing a class, let's call it ClassUnderTest using another class, let's call it OtherClass. In my Test I do:
$OtherClassStub = $this->createStub(OtherClass::class);
$OtherClassStub->method(...)
->willReturn(...);
$ClassUnderTest->otherClass = $OtherClassStub;
That works. But when the $ClassUnderTest calls new OtherClass(), the original OtherClass class is created instead of the stub.
How can I achieve that every possible instance of OtherClass in the context of the test is replaced by the stub?
From your description I infer that in principle you have something like this:
class OtherClass {
protected function someMethod(): bool
{
// determine $x ...
return $x;
}
}
class ClassUnderTest {
public OtherClass $otherClass;
public function methodToBeTested(): bool
{
$otherClass = new OtherClass();
return $otherClass->someMethod();
}
}
class ClassUnderTestTest extends TestCase {
public function testMethodToBeTested(): void
{
$otherClassStub = $this->createStub(OtherClass::class);
$otherClassStub->method('someMethod')
->willReturn(true);
$classUnderTest = new ClassUnderTest();
$classUnderTest->otherClass = $otherClassStub;
$result = $classUnderTest->methodToBeTested();
$this->assertTrue($result);
}
}
Now the assertion in your test may hold or it may fail. Why? Because you are not calling the method you stubbed on the $otherClassStub. Instead you instantiate a new $otherClass object in the method you're testing (or somewhere down the line).
Either your ClassUnderTest should always use the OtherClass object from the ClassUndertTest::otherClass attribute (assuming that's why you put it there in the first place).
Or you could use some other form of dependency injection, e.g. by using a framework like Symfony or Laravel. (In the case of Symfony you can even use only the DependencyInjection Component, no idea if that's possible with Laravel, too.)
The simple answer to your actual question is: you cannot change the behaviour of the new keyword. Calling new on a class will always instantiate a new object based on exactly that class, unless the constructor of that class defines something else.
(You might want to get the concept of classes and objects straight, your code example as well as your question seem to indicate that you're not quite clear on that. Maybe reading up on that as well as on the concept of dependency injection will help you.)
Perhaps a solution to your problem is presented here:
How to Build a PHP Plugin Module System
This is one way to load classes as plugins and they can be called from each other. With modifying this system a bit, you can create as many "new OtherClass()" as you like from your code and still access everything from other classes. If you want multiple instances of a class, perhaps modify it into this direction:
function load ($module,$instance) {
if (isset($this->$module->$instance)) { return true; }
From above link:
<?php
class Core {
// (A) PROPERTIES
public $error = ""; // LAST ERROR MESSAGE
public $pdo = null; // DATABASE CONNECTION
public $stmt = null; // SQL STATEMENT
public $lastID = null; // LAST INSERT/UPDATE ID
// (B) LOAD SPECIFIED MODULE
// $module : module to load
function load ($module) {
// (B1) CHECK IF MODULE IS ALREADY LOADED
if (isset($this->$module)) { return true; }
// (B2) EXTEND MODULE ON CORE OBJECT
$file = PATH_LIB . "LIB-$module.php";
if (file_exists($file)) {
require $file;
$this->$module = new $module();
// EVIL POINTER - ALLOW OBJECTS TO ACCESS EACH OTHER
$this->$module->core =& $this;
$this->$module->error =& $this->error;
$this->$module->pdo =& $this->pdo;
$this->$module->stmt =& $this->stmt;
return true;
} else {
$this->error = "$file not found!";
return false;
}
}
}
ps. thank you for the mod, who made me work a bit more to keep this answer online. the answer is so much better now.
class Testme()
{
public function testMe ($a)
{
if ($a == 1)
{
throw new Exception ('YAY');
}
}
}
so its easy to test if it threw exception
/**
* #expectedException Exception
*/
public function test()
{
new Testme(1);
}
but what if it didn't do anything?
public function test()
{
new Testme(2);
?? ? ? ? ?
}
Scenarios
You have two possible scenarios for a function to do nothing:
Scenario 1: No return statement
Your function does nothing because you do not perform actions in it and you do not include the return keyword in it:
public function doNothing()
{
// Do nothing.
}
Scenario 2: With return statement
Your function does nothing because you do not perform actions in it and you do include the return keyword in it without expressing any return value:
public function doNothing()
{
// Do nothing.
return;
}
Other scenarios
I will leave out of the cases to treat the following scenarios:
Case in which you do not return anything but you perform significant actions that can be tested on other objects. In this case you must unit-test the resulting states of the modified objects.
Case in which you do nothing but return something, then you should unit-test the return value.
Exploring the documentation in the PHP manual
For the first case, the PHP manual documents that the evaluated expression of the function will be null. It says here: http://php.net/manual/en/functions.returning-values.php in a note:
If the return is omitted the value NULL will be returned.
For the second case, the PHP manual documents that the evaluated expression of the funcion will also be null. It says here: http://php.net/manual/en/function.return.php in a note:
If no parameter is supplied, then the parentheses must be omitted and NULL will be returned. [...]
Conclusion
It is therefore clearly documented that a function that "does nothing" necessarily evaluates to null.
How to test a function that does nothing
Just assert your expectations:
$this->assertNull( $sut->doNothing() );
This way you "exercise" your function, you run over it making the code-coverage complete all the lines, and you "expect" that "nothing happened" by testing the null value of its evaluation as an expression, as documented.
How to test a constructor that does nothing
Nevertheless to test a constructor... well... common sense: What's the purpose of a constructor? Create an object (instance) of a certain type (class), right?
So... I prefer to start the 100% of my unit tests by checking that the $sut has been created. This is the VERY first test I write when I'm writing the code of a new class. This is the test I write even before the class exists. At the end, this is what the constructor is for. Red bar. Then I create the class. Green bar.
Let's say I have an Email class that takes a string and will be only created if a valid email is passed and throws exception otherwise. this is very similar to your question. A constructor that just "allows the creation" or "denies it by exploding the system".
I usually would do something like this:
//-------------------------------------------------//
// Tests //
//-------------------------------------------------//
/** #dataProvider validEmailProvider **/
public function testCreationIsOfProperClass( string $email )
{
$sut = $this->getSut( $validEmail );
$this->assertInstanceOf( Email::class, $sut );
}
/** #dataProvider invalidEmailProvider **/
public function testCreationThrowsExceptionIfEmailIsInvalid( string $invalidEmail )
{
$this->expectException( EmailException::class );
$this->getSut( $invalidEmail );
}
//-------------------------------------------------//
// Data providers //
//-------------------------------------------------//
public function validEmailProvider() : array
{
return
[
[ 'alice#example.com' ],
[ 'bob.with-several+symbols#subdomain.another.subdomain.example.verylongTLD' ],
]
}
public function invalidEmailProvider() : array
{
return
[
[ 'missing_at_symbol' ],
[ 'charlie#cannotBeOnlyTld' ],
]
}
//-------------------------------------------------//
// Sut creators //
//-------------------------------------------------//
private function getSut( string $email ) : Email
{
return new Email( $email );
}
As I use PHP 7.0 and I put types everywhere, both entering the parameters and also in the return types, if the created object was not an Email, the getSut() function would fail first.
But even if I wrote it omitting the return type, the test tests what it is expected to happen: new Email( 'valid#example.com' ); is itself an expression that shoud evaluate to "something" of class Email::class.
How to test a constructor that does something
Code smell. The constructor probably should not do work. If any, just store parameters. If the constructor "does work" other than storing parameters consider lazy-processing on getters, or delegating that work in a factory or so.
How to test a constructor that "does nothing but store parameters"
Just like before + then get the data.
Test in your first test that the creation is an instance of something.
Then in another different test, exercise something like a getter that gets you what entered in the constructor even if the constructor did not anything (other than storing it).
Hope that this helps.
In PHPUnit 7.2+ you can also use TestCase::expectNotToPerformAssertions()
public function test()
{
// ...
$this->expectNotToPerformAssertions();
}
This has the same behaviour as the #doesNotPerformAssertions annotation.
2018+
Nowadays the best practice is annotation exactly for these cases:
/**
* #doesNotPerformAssertions
*/
public function testSomething()
{
$someService = new SomeObject();
$someService->shallNotFail();
}
Example pull-request
PHPUnit documentation (poor)
It's not possible. Add return statement and assert the result.
class Testme()
{
public function testMe ($a)
{
if ($a == 1)
{
throw new Exception ('YAY');
}
return true;
}
}
and then
$object = new Testme();
$this->assertTrue($object->testMe(2));
Note: The credits for this solution go to this related answer. The context may seem a little different, but the solution / workaround works the same way. Testing that an exception is not thrown is just the same as testing a method with no return value.
According to this issue thread, there is no built in solution for testing something like DoesNotThrowException in PHPUnit (yet).
So yes, one solution would be to return some dummy value from your method, like
public function testMe ($a)
{
if ($a == 1) { throw new Exception ('YAY'); }
return true;
}
and then assert it in your test. But if you don't want to change the code just for the test, you can work around it:
public function testExceptionIsNotThrown()
{
try {
new Testme(2);
}
catch(Exception $e) {
/* An exception was thrown unexpectedly, so fail the test */
$this->fail();
}
/* No exception was thrown, so just make a dummy assertion to pass the test */
$this->assertTrue(true);
}
It may seem hacky and not very intuitive, but if it's stupid but it works, it's not stupid.
This is an very interesting question, although lot of answers were written, none of them seems to properly answer the question, since you have asked using the class let me explain this way.
Please keep in mind that an instance method you have created in class should have only 2 intentions.
It can alter the state of a class ( change the class properties like private variables )
It returns the state of the class ( getters )
any thing other than this is meaningless unless it is a static method. for example
if you have class like this
class Foo {
private $prop = null;
public function fooMethod() {
$this->prop = "string";
}
public function getProp() {
return $this->prop;
}
}
the method fooMethod() does not return any thing, but it affects the state of $prop property in the class, you can test the method by
$this->assertNotNull( $instance->getProp() );
because you knew if this method is run then the prop $prop should be affected and state of that variable is changed.
Miscellanous Scenario: My method doesn't alter the state and also won't return any state variables.
Then the method is static. It should not be an instance method, and the static methods usually have return type, because they cant affect the state of the class and also can't return state variables. This constraints the static methods from storing a result somewhere (unless you store them globals, don't do that ), so it should definitely return some output. If you don't want to return output, then you could consider returning a boolean from static method.
public function testThrowingException()
{
$this->expectException(Exception::class);
$this->expectExceptionMessage('YAY');
(new Testme())->testMe(1);
}
public function testNotThrowingException()
{
$this->expectNotToPerformAssertions();
(new Testme())->testMe(2);
}
I stumled upon the same problem. To ensure "nothing" has happened it's enough to just call you the method in your unit test. If it fails the test will fail anyway.
If you just call your method without the #expectedException annotation like this
public function test()
{
new Testme(1);
}
you'll get an error
There was 1 error:
1) Testme::testMe
Exception: YAY
Here is the class I am unit testing. Currently I am testing the doSomething function:
class FooClass {
public function doSomething( $user ) {
$conn = $this->getUniqueConnection( $user->id );
$conn->doSomethingDestructive();
}
private function getUniqueConnection( $id ) {
return new UniqueConnection( $id );
}
}
As you can see, the doSomething function gets a new instance of UniqueConnection (a class I am not testing here) based on a property of the argument it receives. The problem is that UniqueConnection:: doSomethingDestructive method is something I cannot call during tests due to its... destructiveness. So I would like to stub/mock the UniqueConnection rather than use a real one.
I don't see any way to inject my mocked UniqueConnection. I would make the UniqueConnection a constructor argument for FooClass but, as you can see, a new one gets created based on the parameter to the doSomething function and all the unique ids it may be called with are not known ahead of time.
My only option that I can see is to test a mock of FooClass instead of FooClass itself. Then I would replace the getUniqueConnection function with one that returns a mock/stub. This seems bad to test an mock, but I don't see any way to achieve what I am after otherwise. UniqueConnection is a third party vendor library and cannot be modified.
You could make a UniqueConnectionFactory, and pass an instance of that to FooClass. Then you have
private function getUniqueConnection( $id ) {
return $this->uniqueConnectionFactory->create( $id );
}
In general, this is one of the benefits of using a factory - you keep the new operator out of the class, which allows you to more easily vary the object being created.
Like Rambo Coder said, it's a matter of doing too much in your class. I wouldn't go as far as wanting to create a Factory, especially if you'll only ever create an instance of one specific class. The simplest solution would be to invert the responsibility of creating the UniqueConnection:
<?php
class FooClass {
public function doSomething( UniqueConnection $connection ) {
$connection->doSomethingDestructive( );
}
}
Pass a mock when you're testing, pass a new UniqueConnection( $user->id ) in the real code..
Until you can take the time to refactor the code to use a factory as rambo coder recommends, you can use a partial mock to return a non-destructive unique connection. When you find yourself in this position, it usually means the class under test has more than one responsibility.
function testSomething() {
$mockConn = $this->getMock('UniqueConnection');
$mockConn->expects($this->once())
->method('doSomethingDestructive')
->will(...);
$mockFoo = $this->getMock('FooClass', array('getUniqueConnection'));
$mockFoo->expects($this->once())
->method('getUniqueConnection')
->will($this->returnValue($mockConn));
$mockFoo->doSomething();
}
Creating classes in a way that it can support different modes of execution is very important in some cases. One of these cases is what you are asking for.
Create your classes to support various modes. For example
Class Connection {
private $mode;
public function setMode($mode) {
$this -> $mode = $mode;
}
}
Now, your doSomethingDestructive can act as per the execution mode.
public function doSomethingDestructive() {
if($this -> mode === "test") { //if we are in a test mode scenario
//Log something
// Or just do some logging and give a message
} else {
// do what it was suppose to do
}
}
Next time, when you are testing the class, you dont have to worry about that destructive function doing something destruction accidentally.
public function doSomething( $user ) {
$conn = $this->getUniqueConnection( $user->id );
$conn -> setMode("test"); //Now we are safe
$conn->doSomethingDestructive(); //But the Testing is still being Ran
}
In this case what you want is not a mock object, but a testing subclass. Break your $conn->doSomethingDestructive(); into a method, then subclass FooClass as TestFooClass and override the new method in the subclass. Then you can test using the subclass without getting the unwanted destructive behavior.
For example:
class FooClass {
public function doSomething( $user ) {
$conn = $this->getUniqueConnection( $user->id );
$this->connDoSomethingDestructive($conn);
}
protected function connDoSomethingDestructive($conn) {
$conn->doSomethingDestructive();
}
private function getUniqueConnection( $id ) {
return new UniqueConnection( $id );
}
}
class TestFooClass extends FooClass {
protected function connDoSomethingDestructive() {
}
private function getUniqueConnection( $id ) {
return new MockUniqueConnection( $id );
}
}
Consider the following, simple class constructor. (note that I am obviously not including all methods that are referenced.
// Initialize User class.
public function __construct($user_id = NULL)
{
// If user is loaded (and a user ID is provided)
if ($user_id)
{
// If user is authorized.
if ($this->authorized($user_id))
{
// Load user information.
$this->info = $this->load($user_id);
}
else
{
// Return an empty (nonexistent) user.
return NULL;
}
}
// If user is loaded (and no user ID is provided)
else
{
// Create a new user.
$new_user = create_user();
// Return the new user's ID.
return $new_user;
}
}
My question is this: is my method of returning values here wrong? My friend insists that a constructor should ALWAYS return an object NO MATTER WHAT. However, the way I have it laid out here seems much simpler, and is much easier to work with. (If I am making a new user, then I get his ID right off the bat. If I am loading an existing user, I immediately have access to her/his information)
If it IS wrong, why? Why is this bad?
What you're trying to do simply doesn't work, the constructor will return the new instance of User anyway, even when you try to return null.
For example, this:
class User {
function __construct() {
return null;
}
}
var_dump(new User());
will print:
object(User)#1 (0) {
}
http://codepad.org/0IdJydkY
You could add a static method to your class to create the user or to return null
public static function createUser() {
// do your checks
// if valid return instance
// return null;
}
$user = User::createUser();
Note: You may have to make your authorized() method static - depends on the rest of your class.
Your __construct() function shouldn't return any value at all, it always automatically returns the object - it should be used to initiate certain things.
I would recommend putting the code in a different function.
More on this can be read here: Echo Return construct method;
This should be so easy. I have a PHP class that has custom methods to return information about objects. I want to use the custom methods to determine whether or not a specific parameter has been set in the object. If it's set, return the property. If not, the method should contact the database to get the information and set the object's property.
However each time I run the code below, it appears that the object's property does not get set. The retrieve_user_first_name method hits the database access object every time.
I've tried checking the value of the property using is_null, empty, isset. I'm feeling like a dope.
require_once('dbaccess.class.php');
class User {
protected $user_id;
protected $first_name;
function __construct($user_id)
{
$this->user_id = $user_id;
}
function __get($variablename)
{
return $this->$variablename;
}
function __set($variablename, $variablevalue)
{
$this->$variablename = $variablevalue;
}
function __destruct()
{
}
function retrieve_user_first_name()
{
if(!isset($this->first_name)) {
$dbAccess = new DBAccess();
$strFirstName = $dbAccess->retrieve_user_first_name($this->user_id);
$this->first_name = $strFirstName;
}
else {
$strFirstName = $this->first_name;
}
return $strFirstName;
}
}
The code you posted works fine.
I think the problem is that you are not using the same object for your sequential calls in whatever code is accessing this object.
So something like:
$ob = new User();
$ob->retrieve_user_first_name();
$ob = new User();
print $ob->first_name;
is happening. Obviously, it's probably not so blatant, but that's the simplest explanation for your problem.
The only other option, given the code you posted, is that all of your database calls are returning empty strings or failing, so the variable is never getting updated. This is a very good possibility, so check both of these options in your code.