Is using test factories in Laravel an anti pattern? - laravel

Question

On this slide :
Sandiz Metz talks about how we should test from the outside without knowing anything about what goes inside the SUT.
I think her talk is focused on the unit tests, not so much about integration tests, but that still made me wonder...could using the factories in Laravel be an anti-pattern ?
It seems to me that using these factories mean I know how the database data has to be for the SUT to complete its task.
For example, say a user has to be able to edit his profile. With factories, I could do this :
/** #test */
public function the_user_can_update_his_profile()
{
$user = factory(User::class)->create();
// ACT
// ASSERT
}
But that knowledge seems to be far too deep and detailed. I have to know how to create a properly registered user. Following the idea of staying in the outside world, shouldn't I instead use an object that already exist to prepare the data for my tests ?
/** #test */
public function the_user_can_update_his_profile()
{
$userRepository = app(UserRepository::class);
$user = $userRepository->register('email#email.com', 'password123');
// ACT
// ASSERT
}
Going even further, how do I know this is the right way to do it ? Shouldn't I simply call the route that a user will use to register ?
/** #test */
public function the_user_can_update_his_profile()
{
$response = $this->json('POST', route('register_user'), ['email' => 'email#email.com', 'password' => 'password123']);
$userRepository = app(UserRepository::class);
$user = $userRepository->find($response['userId']);
// ACT
// ASSERT
}
But that (extreme) solution could also do tons of unnecessary other things (e.g. sending a confirmation email). It also needs the register route to work.
What did you experience as being the cleanest solution for a complicated project ?

Answer 1

As stated in the comments, you're mistaking the purpose and scope of a unit test and an integration test, and from this comes the confusion. Let's start with your "test":
/** #test */
public function the_user_can_update_his_profile()
{
$response = $this->json('POST', route('register_user'), ['email' => 'email#email.com', 'password' => 'password123']);
$userRepository = app(UserRepository::class);
$user = $userRepository->find($response['userId']);
// ACT
// ASSERT
}
This is an integration test. You are testing a "remote" route (okay, it's internal, but you're still testing every single component along the way). An integration test is perfect to confirm that business logic was implemented properly and that the route behaves as expected; it goes through its path from start to completion, testing every interaction between components and the logic in the controller+view itself.
This is all fine and good, but it doesn't really help us that much. We're still blind regarding testability of components themselves. This is where unit testing comes in.
Assume you have a class as follows:
<?php
class Foo {
public $value = 0;
public function __construct($value) {
$this->value = (int)$value;
}
public function getRemainder(int $item) {
return $this->value % $item;
}
}
You may very well end up using this class in one of your controllers; the point of unit testing this is to assert that:
the constructor does store the right value (as an integer)
the isModulo method does what it says on the tin.
To do so, we might write the following test:
public function isActualModuloClass() {
$modulo = new Foo(5);
$modulo_float = new Foo(2.3);
assert($modulo->value == 5, "Integer modulo constructor works");
assert($modulo_float->value == 2, "Float modulo casts to integer properly");
assert($modulo->getRemainder(5) == 0, "Modulo 5%5 is 0");
assert($modulo->getRemainder(4) == 1, "Modulo 5%4 is 1");
}
And sure enough, we've tested every single method, every single branch of our component in isolation. This is a unit test.
It gets messier with classes that interact with other objects, but when structured properly, it is very easy to leverage tools to inject mock copies of objects in order to be able to stub out interactions. When your code touches multiple things at once in an unclean fashion, your tests tend to end up a being gargantuan mess.
The talk you linked is about these tests, and ways to make them not be the fragile mess they tend to be in badly thought-out codebases. In theory, the author is right as well - you start from objects without dependencies, test those, then gradually go up assuming the contracts being established by those are sane and tested, and you work your way up the pyramid. In practice, it's very hard to do when the code is written with testing as an afterthought.