Integration Tests

I updated symfony to 3.4 and phpunit-bridge to ^3.3@dev, with php on 7.1 and phpunit to 8.1, and now it works for me correctly.

Hey Dennis,

It looks like an easy fix, you just need to match the signature of parent TestCase::tearDown() method in our KernelTestCase::tearDown(). You need to tweak the method signature to:

protected function tearDown(): void
{
    // ...
}

as you can see here: https://github.com/sebastianbergmann/phpunit/blob/f462942d1cc58cc02e2c1a247d648c215c208354/src/Framework/TestCase.php#L417-L422

Cheers!

Another option, perhaps the most sensible, is to use the same version of phpunit as the tutorial, the 6.3

OK after about 4 hours of hell I think I might have an answer, maybe you can tell me if I am more or less right. You don´t explicitly set DATABASE_URL yourself.

1) inside the docker container, create a database with the same name as your dev database plus the suffix _test (e.g., my_dev_db_test)
2) inside the docker container, give your dev user full privileges on my_dev_db_test
3) run symfony console doctrine:database:create --env=test
4) run symfony console doctrine:fixtures:load --env=test
5) the coup de graçe that gave me the most trouble: run tests with the command symfony php vendor/bin/phpunit

Hey David,

Yes, all your listed sounds correct! Actually, with the full privileges DB user you can create DB with symfony command you mentioned in step 3. So, the 1st step is redundant then. And yes, when we're talking about Docker - try to use symfony CLI everywhere where possible, as it takes care of setting up env vars correctly for you.

Cheers!

Victor! Sorry to go off-topic but it's good to hear from you, and I fervently hope you and all your people (loved ones, and all the rest) are doing OK under the circumstances, which by all reports are horrendous.

Hey David,

Yes, this is a really hard and horrendous time, probably not only to us but also and to the whole world because the conflict might expand quickly. I'm OK, people are heroically standing, government still does its best I think. Thank you for mentioning this!

Cheers!

Hey Eugene V. Kaurov!

I don't think there is one best practice for how to organize these test directory. Personally I organize integration and unit tests in the same way without any specific separation. If you want to be able to execute the unit tests independently from the integration tests, you could use PHPUnit groups above the classes or methods - e.g. @group integration. Of course, it would also be totally fine to create a structure like tests/integration/ if you like that better :).

Cheers!

Hey, Bruno! I'm glad you liked the idea! :)

Hey Yvon,

It depends, usually devs do not test setters, but if we're talking about form validation - it makes sense. But usually testing that form is valid and entity is actually created in the DB is a better choice, because you may forget to add some validation constraints and form will pass validation but the DB query is failed because of SQL validation constraint.

Cheers!

nice to hear that solution, thanks !

Hey Yvon,

You're welcome! But keep in mind that it may be more resource consuming, as you would need to send queries to the DB, and it takes some time, so your tests may become slower. But as always, look for a good balance. Just don't blindly test everything :) Though, if your project is small, or you just want to practice testing, or this feature is really important in your application - why not to test it ;)

Cheers!

well if it can save me some big stress, I would not hesitate, I don't have much time so I will focus on the most important tests

Hey Yvon,

That's a good strategy to focus on important features first 👍

Cheers!

Hey AmalricBzh

You're 100% correct. I'll fix that ASAP

Thanks for reporting it. Thanks!

Hey avknor

Oh, yes, you are right, this line is causing the troubles

// EnclosureBuilderService
...
66    $diet = $diets[array_rand($diets)];
...

we are going to add a note about it. Thanks for informing us about that pesky bug :)

Cheers!

What is the correct way to avoid this error, without creating a new one?

Hey Arne K. !

To fix the problem of EnclosureBuilderServer "mixing" carnivorous and non-carnivorous dinosaurs, we made a small tweak to the EnclosureBuilderService::addDinosaur() method. Basically, we just moved the $diet = line up a few lines so that when we add the for loop later, this part is not in the loop. In the tutorial, we copy the original EnclosureBuilderService from a tutorial/ directory, and if you download the course code, you'll get the updated version. You can also see the updated version here - https://symfonycasts.com/screencast/phpunit/full-mock-example#codeblock-2505d8fa36 (and if it's helpful, you can see the diff here: https://github.com/knpuniversity/phpunit/commit/ceca8a69b81cfa240cf0b6cd9d3ea92dc2b2fd65).

After we add the for loop, the final product looks like this: https://symfonycasts.com/screencast/phpunit/full-mock-example#codeblock-aabfeeaf56

Let me know if that helps! It was a silly detail we missed, and we don't want it to cause any real issues!

Cheers!

Hey Felipe L.

When you are testing an API integration there are a couple of ways you can do it and it depends on your needs
- Mock the API response. In this case you don't hit the API but you test all the scenarios, when the response was successful, when there was an error, etc.
- Some API's comes with a sandbox, in that case it's totally fine to hit the sandbox and your test will behave almost as in production (I say almost because I've seen some sandboxes that doesn't behave exactly the same as production)
- Hit production API endpoints but using a different account. This some times is useful when the integration to the API is super critical for your application.

Cheers!

Hi MolloKhan , thanks for your reply.

If I'm not mistaken, I've tested mocking API response and definitely tested hitting the production API.
But never tested using a sandbox, I'll have a look at it anyway.

cheers

Cool! So you already know how to test an API integration :)
BTW, not all API's comes with a sandbox, it depends on the third party platform

Cheers!

Yo Shaun T.!

Ah, this was TRICKY! You're not going to like the answer.... :D. Because the tiniest bugs are the hardest to find. Btw, thanks for posting your code - it was the only way I could find the small typo! Here it is - in Enclosure.php:

  /**
   * @var Collection|Security[]
-    * @ORM\OneToMany(targetEntity="AppBundle\Entity\Enclosure", mappedBy="enclosure", cascade={"persist"})
+    * @ORM\OneToMany(targetEntity="AppBundle\Entity\Security", mappedBy="enclosure", cascade={"persist"})
   */
  private $securities;

Yep... it was simply that the relationship was mapped to expect a collection of Enclosure, not a collection of Security objects. Doctrine checks exactly for this, but the exception it throws is honestly not quite as clear as it could be. Hopefully this unblocks you :D.

Cheers!