「テスト」の記事 - Crieit

テスト

2021-04-15T10:16:09+09:00

テスト

LaravelのテストでbelongsToManyのデータをFactoryに作らせる

2019-05-21T10:48:38+09:00

LaravelのFactoryはテストデータ作成がすごく楽で便利。Factoryの定義でリレーションデータも作成するようにしておけば各テストでは一つデータ作成を呼び出すだけでテストができてしまう。

hasOneとかのような1:1のリレーション定義の場合はマニュアルに書かれているような方法で自動生成できる。hasManyやbelongsToManyもテスト実行時にはeachとかでデータを追加することはできるが、できれば定義しておいて省略したい。その場合はちょっと処理の追加が必要。

具体的にはdefineとは別に、afterCreatingとかで追加データを入れてあげれば良い。たとえばpostsにtagsを割り当てる場合はこんな感じ。

$factory->afterCreating(App\Models\Post::class, function ($post, $faker) {
    $random = rand(1, 3);
    $tagIds = [];
    for ($i = 0; $i < $random; $i++) {
        $tagIds[] = factory(Tag::class)->create()->id;
    }
    $post->tags()->sync($tagIds);
});

上記は適当に書いたので、動作確認してないけど下記でも良いと思う。

$factory->afterCreating(App\Models\Post::class, function ($post, $faker) {
    $tagIds = factory(Tag::class, rand(1, 3))
        ->create()
        ->map(function ($tag) {
            return $tag->id;
        });
    $post->tags()->sync($tagIds);
});

Mocha+SuperTestでasync/awaitを使ってテスト

2019-03-07T23:31:07+09:00

MochaとSuperTestを使ったテストで、async, awaitを使ったところ正しい正確な情報が全然見つからずハマったためメモ。とりあえず作った形はこんな感じ。正しいのかは謎だけど一応正しい場合だけちゃんと通るっぽい。

describe('/questions', () => {
  before(async () => {
    app = await getApp()
  })

  it('GET /:id', async () => {
    const question = await QuestionFactory.create()
    return await request(app)
      .get(`/api/questions/${question.uniqueId}`)
      .expect(200)
      .expect(res => {
        if (!res.body.question) throw new Error('Question not found')
        if (res.body.question.name != question.name)
          throw new Error('Question name is not matched')
      })
  })
})

describeにasyncを指定するとおかしくなるので共通処理はbefore等のライフサイクルにて行う。

あとrequest+expectの書き方の正解が上手く見つからず悩んだけど、最終的にawaitしてreturnしたら上手く動くようになった。情報を探すとexpectでdoneしろと書いてあるけどどうもうまくいかないっぽい。

最初にも書いたけど正しい情報か謎なので、どうしても上手くいかなくて困っているという方がいればお試しを。

一人で新規開発する時テストはどのように書き進めればいいか

2018-08-01T13:11:21+09:00

一人でシステムの新規開発をする場合、どういったタイミングでテストを書きはじめ、どのように書いていけばいいかを考察してみた。ターゲットとしては一人でサービスを開発する個人開発者、スタートアップ等で一人のエンジニアのみで開発を進める場合など。

いつから書きはじめるのか

「一人で」システムの新規開発をはじめた当初、まずはテストを書き始めるべきではないと思う。

なぜかというと、新規開発当初に必要なものというのはシステムの安定性ではないからだ。まだリリースもしておらず、身内に確認してもらうためだけのものにテストを書いて時間を消費するのはもったいない。

まずはひたすら開発を行う。闇雲に開発を進めるのではなく、なるべく多くの箇所を網羅できるように、薄く広く開発していく。そうすることで不明点やもっと検討が必要であるべき箇所が見つかり、それを企画サイドの人間に共有することで早めのプラン改善を行うことができる。

いきなり丁寧にテストを書きはじめてしまい、だいぶ日数が経過してから大きな問題が見つかり「実は予定していた機能は今の方法では実現できないんだ」なんてことになったら大問題だ。ただでさえ無駄なものを開発することに時間を費やしてしまっているのに、さらにテストを書くのにも時間を費やしてしまうことになる。時間はもう二度と取り戻せないのにそんなことをやっている場合ではない。

そういった理由でまずはテストを書くべきではない。

一人での開発に求められること

そもそも一人で開発を行う場合に求められること（もしくは自分で求めること）というのは、単なるプログラム開発だけではない。

ちょっと仕様を変えれば格段に開発がしやすくなるのであればそれを企画サイドに提案してみたりすること等も重要だ。こういったことは必須ではないが重要で、開発者一人だけの時にこういった連携や提案を率先してできない場合、トラブルの原因にもなりうる。

同様にテストをどう書いていき、どのように時間を節約し、どのようにスムーズな開発を提供できるかというのは一人の場合非常に重要となる。考えることを放棄してむやみにテストを大量に書いていくべきではない。

ではどのように書いていけばいいのか

とりあえず一通りの機能はテストなしで作成していくべきだ。問題点や仕様の変更の必要性がある箇所の洗い出しが終わり、ある程度企画サイドとのやり取りも落ち着いてきた時期に、リリースに向けてどんどん書いていくべきだと思う。

一応「一人で」という体にはなっているが、複数人の時でも考えることは放棄せず一応方針は決めたほうがいいと思う。人数が多い時は最初からテストを書いていった方が望ましい場合は多いかもしれないし、２，３人の時は書かない方がいいかもしれなし、書いた方がいいかもしれない。

まずはその都度その状況において、書くこと、書かないことのデメリットを必ず検討してみよう。

コメントテスト

2018-06-17T21:27:11+09:00

コメントテストです。どなたでも自由にコメントしてください。