2017-01-03 3 views
0

Что следует учитывать при проведении единичного теста? Какие шаги? Какие случаи? Сколько тестов на каждую функцию? и т.д.Что следует учитывать при проведении модульных тестов?

Я также хотел бы получить информацию о вашем опыте. Также я работаю с laravel phpunit. Я сделал пример, и он работал:

public function test_for_clientUser() { 
    $this->json('POST', 'clientUser', ['id'=>'232421'])->seeJsonStructure([[]]); 
} 

Я отправляю запрос с идентификатором и возвращает массив. Что еще продиссея вы добавляете к этому тесту?

+0

тесты должны проверить предполагаемый результат, а не извлечение данных. Вы предполагаете, что ответ будет структурой json или что ответ будет успешным. Вы не проверяете специфику ответа. Вы проверяете ** логику **, а не данные. Подробнее о тестировании Laravel можно найти здесь (https://laravel.com/docs/5.0/testing). – Peon

ответ

0

Вы можете разделить свои тесты на несколько действий (список, магазин, Показать, Update, Delete, и т.д.) для каждого контроллера.

Например, вы можете протестировать проверку входных данных для некоторой почтовой формы:

public function testStoringCityAsOwnerWithNotExistingCountryId() 
{ 
    $input = [ 
     'country_id' => 0, 
     'translations' => [ 
      [ 
       'name' => 'Варна', 
       'lang' => 'bg' 
      ] 
     ] 
    ]; 

    $response = [ 
     'errors' => [ 
      'country_id' => [ 
       trans(
        'validation.exists', 
        ['attribute' => 'country id'] 
       ) 
      ] 
     ] 
    ]; 

    $this->asOwner() 
     ->post('/cities', $input, $this->headers) 
     ->seeStatusCode(ResponseCode::PERMISSIONS_DENIED) 
     ->dontSeeJson(); 
} 

Также вы можете проверить свой листинг информации, разбиение на страницы и много много других случаев , которые вы можете найти, как ошибку. На самом деле отверстие концепции является то, что для каждой ошибки вы должны написать новый тест!

0

Согласно этому примеру (из Lumen Руководство по программированию): https://github.com/Apress/lumen-programming-guide/blob/master/tests/app/Http/Controllers/BooksControllerTest.php

Вы бы испытать более или менее это:

GET /index 
    - status code is 200 
    - returns a collection of (well-formed) records 

GET /show 
    - status code is 200 
    - returns a valid (well-formed) resource 
    - should fail with a non existing id (404) 
    - should not respond with 200 if id is not numeric. Maybe 404 

POST /store 
    - the resource stores in DB 
    - returns code 201 CREATED 
    - returns a valid json qith a resource id 

PUT /update 
    - status code is 204 
    - the resource has not the new value in DB 
    - the resource now has updated data in DB 
    - modified date was updated 
    - should fail with a non existing id (404) 
    - should not respond with 204 if id is not numeric. Maybe 404 

DELETE /destroy 
    - returns 204 
    - should fail with a non existing id (404) 
    - should not respond with 204 if id is not numeric. Maybe 404 

Как вы изменяете DB (чем должно быть тестовая БД, как экземпляр SQLite, работающий в памяти), это не единицы, но, возможно, функциональные. Я не могу заверить. Автор называет их приемом тестов, но они не являются, так как они белым ящиком тесты (манипулирование БД напрямую).

Смежные вопросы