Chapters

20 Chapters | 1:32:53 |

01

POST To Create

7:47
02

Finish POST with a Form

4:42
03

Handling data with a Form

5:03
04

GET one Programmer

3:20
05

Tightening up the Response

3:51
06

GET a Collection of Programmers

5:24
07

Add a Test!

3:00
08

Test Code Reuse

2:31
09

Tests with the Container

4:23
10

Mad Test Debugging

3:03
11

Test Fixtures and the PropertyAccess Component

6:24
12

The ResponseAsserter!

6:21
13

Using a Test Database

6:52
14

PUT is for Updating

6:41
15

Read-Only Fields

3:26
16

DELETE is for Saying Goodbye

2:59
17

PATCH is (also) for Updating (basically)

3:18
18

Using a Serializer

5:47
19

Centralize that Response!

2:40
20

Taking Control of the Serializer

5:21

This tutorial has a new version, check it out!

> APIs > Symfony RESTful API: Course 1

Buy Access to Course

16.

DELETE is for Saying Goodbye

|

Autoplay

Keep on Learning!

If you liked what you've learned so far, dive in! Subscribe to get
access to this tutorial plus video, code and script downloads.

Start your All-Access Pass

Buy just this tutorial for $10.00

Previous Chapter

Next Chapter

Login or register to check out the script

2 Comments

Sort By

Login or Register to join the conversation

Victor SFCASTS 8 years ago

I think we also should to send GET request and try to get this programmer by `$nickname` in tests and ensure that it doesn't exist anymore. What if we do something wrong in `deleteAction` (for example wrong DB query in `findOneByNickname` method) and programmer don't really delete? It almost always returns us a `204`, but programmer could not be deleted, so we need to check it too, right?

1 |

weaverryan SFCASTS Victor 8 years ago

Hey!

I'm mixed on this. Well, obviously, doing what you're saying is probably best - and I like the idea that you're actually using the API to verify the delete. So why *wouldn't* I test this? Because I don't want to over-test. The only likely way that this could return a 204 but NOT delete is if we actually just forgot the save logic (any error would cause a 500). And as long as we manually play around with our API once or twice, we'll notice that it doesn't actually save. Unlike other bugs (the ones that cause errors), there's basically no risk that we'd add a regression where we accidentally deleted the save code later.

I'll admit, this over-testing in functional tests is more possible when you're testing a web interface (e.g. don't submit a form 50 times to test all 50 different validation combinations), but that was the idea here.

Anyways - if you want to test it, I like your way :)

Cheers!

1 |

This tutorial uses an older version of Symfony. The concepts of REST are still valid, but I recommend using API Platform in new Symfony apps.

Symfony 2

What PHP libraries does this tutorial use?

// composer.json
{
    "require": {
        "php": ">=5.3.3",
        "symfony/symfony": "2.6.*", // v2.6.11
        "doctrine/orm": "~2.2,>=2.2.3,<2.5", // v2.4.7
        "doctrine/dbal": "<2.5", // v2.4.4
        "doctrine/doctrine-bundle": "~1.2", // v1.4.0
        "twig/extensions": "~1.0", // v1.2.0
        "symfony/assetic-bundle": "~2.3", // v2.6.1
        "symfony/swiftmailer-bundle": "~2.3", // v2.3.8
        "symfony/monolog-bundle": "~2.4", // v2.7.1
        "sensio/distribution-bundle": "~3.0,>=3.0.12", // v3.0.21
        "sensio/framework-extra-bundle": "~3.0,>=3.0.2", // v3.0.7
        "incenteev/composer-parameter-handler": "~2.0", // v2.1.0
        "hautelook/alice-bundle": "0.2.*", // 0.2
        "jms/serializer-bundle": "0.13.*" // 0.13.0
    },
    "require-dev": {
        "sensio/generator-bundle": "~2.3", // v2.5.3
        "behat/behat": "~3.0", // v3.0.15
        "behat/mink-extension": "~2.0.1", // v2.0.1
        "behat/mink-goutte-driver": "~1.1.0", // v1.1.0
        "behat/mink-selenium2-driver": "~1.2.0", // v1.2.0
        "phpunit/phpunit": "~4.6.0" // 4.6.4
    }
}

Previous Chapter

Next Chapter