Skip to content

Latest commit

 

History

History
172 lines (127 loc) · 6.11 KB

6.md

File metadata and controls

172 lines (127 loc) · 6.11 KB

Practical Work #6 — The End!

This is your last practical, hurray! First of all, if you didn't see these tweets yet, it's worth reading them:

Authentication

Add an authentication layer as described in class.

  1. Your users can be authenticated so that they can retrieve their own statuses, and create new ones with their names,
  2. Only users can delete their own statuses,
  3. It is still allowed to create new statuses anonymously.

Testing

Functional Tests

Functional tests are tests that ensure correctness of your application by focusing on use cases/user stories.

User Stories vs Use Cases

Did I mention the difference between use cases, and user stories? I guess no. According to Wikipedia (eurk), a user story is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function. Most of the time, we use the following pattern to represent a user story:

"As a <role>, I want <goal/desire> so that <benefit>"

According to Wikipedia, a use case is a list of steps, typically defining interactions between a role (known in UML as an "actor") and a system, to achieve a goal. The actor can be a human or an external system. It's more formal, and verbose.

In-Depth With Functional Testing

The goal of functional testing is to not only test a method, but this method and its interactions with the rest of the application. In other words, they test the system the way the end user would use it.

For instance, you cannot test a controller because its job is to glue all components of your application to fit a given use case. For example, a controller relies on the Model layer to retrieve data, and uses the View layer to render the data to the client.

You can write your first functional tests by testing your Mapper using a configured Connection instance (leveraging the SQLite database), instead of using a mock.

<?php

class StatusDataMapperTest extends TestCase
{
    private $con;

    public function setUp()
    {
        $this->con = new \Model\Connection('sqlite::memory:');
        $this->con->exec(<<<SQL
CREATE TABLE IF NOT EXISTS statuses (
    ...
);
SQL
        );
    }

    public function testPersist()
    {
        $mapper = new \Model\StatusDataMapper($this->con);

        // ...

        // Example on how to count rows in the table
        // $rows = $this->con->query('SELECT COUNT(*) FROM statuses')->fetch(\PDO::FETCH_NUM);
        // $this->assertCount(0, $rows[0]);
    }
}

Test your Model layer using SQLite.

Another part you may want to test is the API. It's a pain to use curl to test each API method, and we don't do that in real life. Instead, give Goutte a try. It is a simple PHP web scrapper:

<?php

$client   = new Client();
$endpoint = 'http://localhost:8090';

// GET
$crawler  = $client->request('GET', sprintf('%s/statuses', $endpoint));
$response = $client->getResponse();

// POST
// See: https://github.com/symfony/BrowserKit/blob/master/Client.php#L242
$client->request('POST', sprintf('%s/statuses', $endpoint), $request, [], $headers, $content);

// Examples of assertions:
// $this->assertEquals(200, $response->getStatus());
// $this->assertEquals('text/html', $response->getHeader('Content-Type'));
//
// $data = json_decode($response->getContent(), true);
// $this->assertArrayHasKey('message', $data);

Test your API using this client. Your application has to run in order to test it.

You can also use Behat (and Mink) to describe scenarios.

Important

Le projet de PHP est à rendre le 14/02/2016 à 20h00 CET. Il s’agit de terminer les TPs (on s’arrête au sujet #6, c'est-à-dire ici), ce qui implique la gestion des statuts. Vous pouvez faire quelque chose de "joli", au moins un minimum mais ce n’est pas la priorité.

Les formats acceptés sont :

  • une archive (tar, tgz ou zip) ;
  • ou un dépôt distant (git, etc.).

Le projet doit être accompagné des instructions de mise en route. Ainsi que d'un bilan rapide de ce qui a été fait/pas fait. Le format pour ce fichier doit être textuel, donc txt ou markdown. Je n’ouvre pas de fichiers Word ou Open Office.

Ce bilan n'est pas un compte rendu formel, vous pouvez simplement énumérer ce qui a été fait et ce qui n'a pas été fait, en faisant des phrases courtes. Il devrait tenir sur une page, et c'est un fichier obligatoire.

Aucun retard ou problème technique ne sera toléré, c'est pourquoi il est fortement conseillé de mettre également à disposition un lien de téléchargement direct sur un service en ligne (ownCloud, Dropbox, Ubuntu One, Google Drive, etc.).

Si votre archive est corrompue, vous serez défaillant, faites en sorte d'envoyer quelque chose de correct. Je vérifierai ce point à chaque réception d'un projet. Si votre archive est corrompue, je vous le dirai et vous aurez avant 20h00 pour renvoyer une archive valide.

Vous devez nommer l'archive comme suit : projet_<nom 1>_<nom 2>_.zip. Le mail doit comporter la mention [PROJET PHP #1] dans le sujet du mail. Comme je vous l’ai dit, la pénalité de retard se comptera à la minute près ;-)

Concernant le partiel : 1h pour 30 à 40 questions rapides (QCM et questions rapides), pas besoin de connaître les fonctions cachées de PHP, il n’y aura pas de code à écrire. Il faut connaître les principes vus en cours, et surtout ce que j’ai pu raconter (sauf les blagues/anecdotes, ce qui laisse finalement peu de choses à revoir). No stress!

Si vous avez des questions, je reste disponible.