UnitTest はなぜ大事なのか?自分たちのミスに気付かないミス

ヘルメットを着用して安全に備えるビジネスマン
ヘルメットを着用して安全に備えるビジネスマン フリー素材ぱくたそ(www.pakutaso.com)
  • URLをコピーしました!

ツチノコテクノロジーでは、Laravelでのシステム開発の際に、必ず UnitTest を作成します。
UnitTest はめんどいとか、UnitTestを書いている工数が無いなどと言って、UnitTest を作らない選択をしているプロジェクトはありません。

理由は1つで、「自分たちのミスに自分たちで気づく」ためです。

目次

自分たちのミスに自分たちで気づく

あなたが既存システムの機能を修正しているとします。
2つの関数を修正しました。どちらもいくつかのクラスに呼び出される関数です。

引数を追加しただけなので、既存の処理に影響はないはず。
影響調査もしたし、机上デバックでも問題ないとわかっているとか、そういう理由を使ってUnitTestを作っていないプロジェクトはまだまだあります。

しかし、本当にささいなことでバグは発生します。
わたしはこの前、クラス内で使っている配列のキーを変更したら、別の画面でバグがでたことを思い出しました。配列のキーをデータベースに保存していたためです。この場合、画面を表示したらエラーが表示されたので、画面を表示することさえしていたら、気づけました。
こういうささいなことでも、影響って出ます。

このとき、もし最低限の UnitTest 、例えば、すべてのルート( routes\web.php で定義している GET と POSTすべて)に対して、「アクセスしたら HTTP レスポンスステータスコード200を返す」「アクセスしたらリダイレクトされて、 HTTP レスポンスステータスコード302を返す」だけのテストを作っていれば、上のミスは自分で気づくことができました。エラーが出れば、 HTTP レスポンスステータスコードは500になるからです。

Laravelの最初から入っているExampleTestをちょっと修正すれば、防げたミスでした。ルートのテスト作成は、5分とかかりません。ExampleTestのソースコードはこんな内容です。

<?php

namespace Tests\Feature;

use Tests\TestCase;
use Illuminate\Foundation\Testing\RefreshDatabase;

class ExampleTest extends TestCase
{
    /**
     * A basic test example.
     *
     * @return void
     */
    public function testBasicTest()
    {
        $response = $this->get('/');

        $response->assertStatus(200);
    }
}

例えば GET: /posts という記事一覧のルートがあったとします。 php artisan make:test PostsControllerTest とすれば、ここまで準備してくれます。

<?php

namespace Tests\Feature;

use Illuminate\Foundation\Testing\RefreshDatabase;
use Illuminate\Foundation\Testing\WithFaker;
use Tests\TestCase;

class PostsControllerTest extends TestCase
{
    /**
     * A basic feature test example.
     *
     * @return void
     */
    public function test_example()
    {
        $response = $this->get('/');

        $response->assertStatus(200);
    }
}

ちょっと整えるだけです!

<?php

namespace Tests\Feature;

use Illuminate\Foundation\Testing\RefreshDatabase;
use Illuminate\Foundation\Testing\WithFaker;
use Tests\TestCase;

class PostsControllerTest extends TestCase
{
    use RefreshDatabase;

    /**
     * A basic feature test example.
     *
     * @return void
     */
    public function test_posts()
    {
        $response = $this->get('/posts');

        $response->assertStatus(200);
    }
}

これで、もし仮にいろいろ修正した際に GET: /posts にアクセスしたときにエラーが出てしまったとしても、作業のあとに php artisan test を実行しておけば、ここから先、ずっと自分のミスに自分で気づくことができます。

公式情報 Laravel 8.x テスト: テストの準備
https://readouble.com/laravel/8.x/ja/testing.html

「やらかし」を許す

人間だれしも、完璧ではありません。

「よっしゃ終わったー!リリース、ポン!はい帰ろう!」ってなります。
確認忘れててもしょうがないです。

これが金曜日の夜19時で、あなたが帰ってのんびり過ごして早めに寝ようとしているのだとして、お客さまから22時半に電話がかかってきて「/posts 画面が表示されないよ!週末はアクセスが多いからすぐに修正して!」と言われて、すぐに直せるでしょうか?

もうお酒を飲んでしまっているかもしれません。
ゲーム中はスマホの電源を切ることにしていて、気づかないかもしれません。

しかし、上のUnitTestを作成しておけば、リリース前の数分(大きいシステムだともっと長いかもしれませんが)待つだけで、このミスを防ぐことができます。すべては自分のためですし、チームの他のメンバーのためです。

UnitTestを作っていないプロジェクトを見つけたら、工数うんぬんではなく、とにかくHTTPリクエストのテストだけでも作成しましょう!1日もかからないです!って伝えましょう!それだけで、リリース時のやらかしの大半を防げると思います!

ツチノコテクノロジーに開発・保守を発注しませんか?

Laravel・Flutterの開発・保守をツチノコテクノロジーに発注しませんか?

まずはZOOMで打ち合わせ

お申し込みはこちら

ツチノコテクノロジーでは一緒に働く仲間を募集しています!

完全リモートで働きたい方へ!

詳しくは以下をご覧ください。

ツチノコテクノロジー採用サイト

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

ツチノコテックアカデミアの記事は、社内で誰かが質問してくれたことに回答したときに、ついでに記載しています!(^^)/
みんなの悩みを共有すれば、きっと誰かの役に立つと信じて更新しています!

目次