As a base I use \Codeception\TestCase\Test class.
And I noticed that for every test* methods defined in class, codeception recreates TestCase\Test class !
But Why?
As result I can't use class fields!
public function getName() {
if (!empty($this->_name)) {
return $this->_name;
} else $this->_name = uniqid('_name');
}
getName() for every test method will return new generated name.. thats wrong behavior as for me. It's possible to resolve this situation if I wants to use class fields for every test methods, like in normal OOP?
Related
So I have a service method that modifies a model object
public function doSomething() {
$model = new Model();
// Modify the model with a bunch of private methods
return $model;
}
If I want to test doSomething, I really only have $model to work with. And the only way I can write assertions on $model is to use its public interfaces.
$this->assertEquals($model->getName(), 'name');
What confuses me here is what exactly am I testing with that assertion? Am I testing that getName works properly or am I testing doSomething works properly?
In order for me to test doSomething, I have to assume that getName works. So how do I make sure that is the case?
Based on your code, I would test that I got an instance of Model returned. And then using the public accessors or assertAttributeEquals to check that the properties of the object were correct. This does test the getters of the model, however the object having certain properties is what you are expecting to happen.
Though as your class is both creating the object and modifying it. I would change the method to take a Model as an argument. This way in my test I can create a mockModel and make sure that any public setters are called with the proper arguments. Doing this, I don't have to worry about any of the logic that Model has for properties that get set.
For Example:
Test Function:
public function testDoSomething() {
$mockModel = $this->getMock('Model');
$mockModel->expects($this->once())
->method('foo')
->with('some argument');
$mockModel->expects($this->once())
->method('bar')
->with('some other argument');
$sut = new SUT();
$sut->doSomething($mockModel);
}
Your function doSomething only needs to become this:
public function doSomething(Model $model) {
/** Do stuff with private methods **/
}
Now you are able to make sure that properties of Model are set with the proper values and not depending on the logic that may or may not exist in the class. You are also helping to specify the contract that Model needs to fill. Any new methods that you are depending on will come out in your integration / system tests.
Your contract with doSomething() is, that it has to return an object of type "Model". Your contract is not getName() working on a returned object. As result, test $model to be of correct type:
$this->assertInstanceOf('Model', $model);
Documentation: PHPUnit -> assertInstanceOf()
As a hint, "[i]deally, each test case is independent from the others" 2014-10-21 wikipedia.org/wiki/Unit_testing.
So, in your test_doSomethingTest*(), you are supposed to test only what happens within that function. Check for return type, and whatever happens withing that function. Testing getName() should be in it's own test_getName*().
When you're instantiating an object of a class that inherits from a parent class the constructor calls the superclasses constructor in most langiages I know and my question is: when the superclasse's constructor is called there will effectively be an object of that type in memory, but we're creating an object of the subclass with(in this example) additional values to add to the object so how is that accomplished in memory? Is it added to the original object? Are the contents of the original object copied into a new object with space for all the variables? Or is it something completely different?
A different question that just occured to me, are class variables, like in java, kept in the data segment of the program in memory? How are classes, not the objects, stored in memory for that matter?
Thanks.
I don't really know how engine works, but I know how to test memory usage in PHP. Both scripts
class base {
public function __construct() {
}
}
$start_memory = memory_get_usage();
$object = new base;
echo memory_get_usage() - $start_memory;
and
class base {
public function __construct() {
}
}
class derived extends base {
public function __construct() {
}
}
$start_memory = memory_get_usage();
$object = new derived;
echo memory_get_usage() - $start_memory;
return the same value. It means there'is only one instance in memory, not parent + it's child, when class is extended
phpfiddles: 1st script, 2nd script
Classed are code that define its object, so they are in Code Segment of program. And all class variables are in data segment.
And when we create an object of subclass, first its parents' object are created and it is extended for subclass members. That's why subclass object has all members of its parent class.
I have a code like this:
public class MyTest extends TestCase {
private MyObject mObject1;
private MyObject mObject2;
...
#Override
public void setUp() throws Exception {
super.setUp();
}
public void testSomething() {
mObject1 = new MyObject();
mObject2 = new MyObject();
}
public void testSomething2() {
// Here I can't access the previously created objects mObject1 and
// mObject2, because they are again null.
// Why is that, if *my* setUp() method doesn't touch them?
}
My guess is that JUnit instantiates the class again every time. Can someone please explain me the workflow?
Thanks.
JUnit will instantiate the class (MyTest) once per test and then execute the methods
setUp()
testXXX()
tearDown()
until it runs all the methods that start with test and don't receive any parameters. So in your example, Junit will instantiate MyTest twice. You can read more about this in the JUnit documentation.
Bear in mind that this is the old way of writing tests. From Junit 4 (I think) the preferred way is to use annotations. You can check the annotations documentation here.
As a side note, NUnit, reuses the instance of the test, so in the same scenario, it would only instantiate MyTest once.
JUnit will instantiate this class once per test method, so only once in the code above, but try it again with two test methods and you will see it instantiated twice. If you want to save some state in fields without having to use statics, take a look at TestNG, which reuses the same instance for all test methods.
I have a class that has two methods. One method needs to call the other method and in my test I want to assert that it was called.
public class Tasks : ITasks
{
public void MethodOne()
{
MethodTwo(1);
}
public int MethodTwo(int i)
{
return i + 1;
}
}
I want to mock Tasks and do something like tasks.AssertWasCalled(x => x.MethodTwo(1)). Must MethodTwo be virtual?
The concept you're looking for is partial mocks (this shows old syntax, but I don't remember the new one off the top of my head). You should read up on it. Essentially you create the mock on Tasks (not ITasks) and tell it to mock out only MethodTwo (which needs to be virtual).
However...you might want to reconsider your design. What is ITasks? What is the role? Are they different actual tasks? Is there any reason why you would want them in the same class? My understanding is that partial mocks is only included for when you need to test legacy components - I've never found a use for it.
Of course my thinking at that time was flawed. I should be mocking ITasks, not the implementation (Tasks):
ITasks tasks = MockRepository.GenerateMock<ITasks>();
tasks.AssertWasCalled(x => x.MethodTwo(Arg<int>.Is.Equal(1)));
Can a class return an object of itself.
In my example I have a class called "Change" which represents a change to the system, and I am wondering if it is in anyway against design principles to return an object of type Change or an ArrayList which is populated with all the recent Change objects.
Yes, a class can have a method that returns an instance of itself. This is quite a common scenario.
In C#, an example might be:
public class Change
{
public int ChangeID { get; set; }
private Change(int changeId)
{
ChangeID = changeId;
LoadFromDatabase();
}
private void LoadFromDatabase()
{
// TODO Perform Database load here.
}
public static Change GetChange(int changeId)
{
return new Change(changeId);
}
}
Yes it can. In fact, that's exactly what a singleton class does. The first time you call its class-level getInstance() method, it constructs an instance of itself and returns that. Then subsequent calls to getInstance() return the already-constructed instance.
Your particular case could use a similar method but you need some way of deciding the list of recent changes. As such it will need to maintain its own list of such changes. You could do this with a static array or list of the changes. Just be certain that the underlying information in the list doesn't disappear - this could happen in C++ (for example) if you maintained pointers to the objects and those objects were freed by your clients.
Less of an issue in an automatic garbage collection environment like Java since the object wouldn't disappear whilst there was still a reference to it.
However, you don't have to use this method. My preference with what you describe would be to have two clases, changelist and change. When you create an instance of the change class, pass a changelist object (null if you don't want it associated with a changelist) with the constructor and add the change to that list before returning it.
Alternatively, have a changelist method which creates a change itself and returns it, remembering the change for its own purposes.
Then you can query the changelist to get recent changes (however you define recent). That would be more flexible since it allows multiple lists.
You could even go overboard and allow a change to be associated with multiple changelists if so desired.
Another reason to return this is so that you can do function chaining:
class foo
{
private int x;
public foo()
{
this.x = 0;
}
public foo Add(int a)
{
this.x += a;
return this;
}
public foo Subtract(int a)
{
this.x -= a;
return this;
}
public int Value
{
get { return this.x; }
}
public static void Main()
{
foo f = new foo();
f.Add(10).Add(20).Subtract(1);
System.Console.WriteLine(f.Value);
}
}
$ ./foo.exe
29
There's a time and a place to do function chaining, and it's not "anytime and everywhere." But, LINQ is a good example of a place that hugely benefits from function chaining.
A class will often return an instance of itself from what is sometimes called a "factory" method. In Java or C++ (etc) this would usually be a public static method, e.g. you would call it directly on the class rather than on an instance of a class.
In your case, in Java, it might look something like this:
List<Change> changes = Change.getRecentChanges();
This assumes that the Change class itself knows how to track changes itself, rather than that job being the responsibility of some other object in the system.
A class can also return an instance of itself in the singleton pattern, where you want to ensure that only one instance of a class exists in the world:
Foo foo = Foo.getInstance();
The fluent interface methods work on the principal of returning an instance of itself, e.g.
StringBuilder sb = new StringBuilder("123");
sb.Append("456").Append("789");
You need to think about what you're trying to model. In your case, I would have a ChangeList class that contains one or more Change objects.
On the other hand, if you were modeling a hierarchical structure where a class can reference other instances of the class, then what you're doing makes sense. E.g. a tree node, which can contain other tree nodes.
Another common scenario is having the class implement a static method which returns an instance of it. That should be used when creating a new instance of the class.
I don't know of any design rule that says that's bad. So if in your model a single change can be composed of multiple changes go for it.