テスト自動化(CI)

テスト自動化(CI)色々なテストコードを作成してみよう

↓↓↓はじめて講座を受ける方はこちら↓↓↓
開発環境を作ろう

色々なテストコードを作成してみよう の講座の6レッスン目。

最後は自動テストをGitHub Actions上で動作させてみます。

前回のレッスンはこちら↓

ウサギ
ウサギ

前回までで必要なすべてのテストを学ぶことができた

ウサギ
ウサギ

最後はソースがリポジトリにpushされたら自動でテストを回す方法を学んでいく

ウサギ
ウサギ

いわゆる、CI(Continuous Integration)ってやつだ

わいへい
わいへい

シ、シーアイ??

CIは「継続的インテグレーション」と訳される。

1回のコミットを小さくし、masterブランチと、機能開発ブランチを頻繁にマージしながら素早く機能開発して行こうぜっていうやつだ。

マージやコミットの度に、自動でテストを実施することで、誰がなんの原因で機能を壊したのかを早期発見できるのがキモだ。

昔は2週間に1回みんながリリースブランチへガッとマージして、ビルドチームが1日かけて手動でソフトウェアをビルド、んでビルドエラーや大きな不具合があったらメーリングリストにメールして、原因を作ったやつがそれを直すまで開発が止まる〜。。。みたいな状況があるあるだった。

今はそういう現場は少なくなってきた。

使いやすいCIツールが増え、情報が整備されたことで、CIのハードルがだいぶ下がってきた。

今回は、CIツールの中でも、GitHub Actionsを使って、

  • GitHubのリポジトリの
  • featureブランチにpushされたら
  • pushされたブランチのソースで自動テストが走り
  • 結果をGitHub上に表示する

ということをやってみる。

この講座で学んできた自動テストはCIに組み込んで初めて完成する。

必ずできるようになってくれ。

ベースアプリの準備

では準備をしていくぞ。

今回はいつも使っているベースアプリのリポジトリをfork(複製)して、自分のリポジトリを作って作業する。

リポジトリのfork

ウサギ
ウサギ

ベースのアプリを複製して、自分用のリポジトリを作る

まずは下記にアクセスし、

GitHub - yheihei/base_diary: ウサでも分かる中級Django講座の教材
ウサでも分かる中級Django講座の教材. Contribute to yheihei/base_diary development by creating an account on GitHub.

右上のforkボタンを押す。

数秒後、自分のリポジトリとして複製が完了する。

コピーしたリポジトリをgit cloneで取り込んでおく。今後は↓のソース内をいじっていくぞ。

$ git clone https://github.com/自分のGitHubユーザー名/base_diary.git
$ cd base_diary

完成版ソースを見る場合

ウサギ
ウサギ

自動テストの設定をしたブランチも用意しておいた

答えだけ先に見たいやつは下記コマンドでチェックアウトしてくれ

GitHub - yheihei/base_diary at feature/#7-test-ui
ウサでも分かる中級Django講座の教材. Contribute to yheihei/base_diary development by creating an account on GitHub.
# テストコードがすでに書いてあるブランチを見たい場合はこちら
$ git fetch && git checkout feature/#7-test-ui

CIツール上での自動テスト 完成版

featureブランチにpushすると、GitHub Actions上で自動テストが実行されるようになる。

下記のURLを見ると、push時に自動でテストが行われ、テストが成功していることがわかる。

Actions · yheihei/base_diary
ウサでも分かる中級Django講座の教材. Contribute to yheihei/base_diary development by creating an account on GitHub.

このテスト自動実行の仕組みで、バグを本番環境に流出させないようにするのが狙いだ。

GitHub Actionsの設定を追加する

それでは設定を行っていく。

まずは、下記コマンドで作業ブランチを作り、チェックアウトしておく。

$ git checkout -b feature/add_github_actions

GitHub Actionsの設定

.github/workflows/django.ymlファイルを作ってGitHub Actionsの設定を行う。

下記のように書く。

name: Django CI

on:
  push:
    branches: [ feature/** ]  # feature/hogeブランチにpushされたら jobsが実行される

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      max-parallel: 4
      matrix:
        python-version: [3.9]

    steps:
    - uses: actions/checkout@v2
      with:
        ref: ${{github.head_ref}}
    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v2
      with:
        python-version: ${{ matrix.python-version }}
    - name: Install Dependencies
      run: |
        python -m pip install --upgrade pip
        pip install -r requirements.txt  # requirements.txtから必要なpythonモジュールをインストールする
    - name: Run Tests
      run: |
        python manage.py test  # テスト実行する

重要なところをかいつまんで解説する。

まず、下記でこのjobがどのタイミングで実施されるかを書いている。

on:
  push:
    branches: [ feature/** ]  # feature/hogeブランチにpushされたら jobsが実行される

次に、必要なpythonモジュールをrequirements.txtの定義からインストールする。

    - name: Install Dependencies
      run: |
        python -m pip install --upgrade pip
        pip install -r requirements.txt  # requirements.txtから必要なpythonモジュールをインストールする

最後に、テスト実行だ。

    - name: Run Tests
      run: |
        python manage.py test  # テスト実行する

requirements.txtを追加する

次に、pythonのモジュールをインストールするときに使うrequirements.txtを書いていく。

今回の場合は下記の記述だけで良い。

Django==3.2.6

Djangoのバージョンを指定しているが、別になくても良い。

また、pip freezeを使って自分のPython環境をそのままrequirements.txtに書いても良い。

$ pip freeze > requirements.txt

余分なモジュールが入ると困る場合はrequirements.txtを直接書いたらいい。

適当なテストコードを書く

では最後に、適当なテストコードを書く。今回は絶対に成功するテストを書いておく。

from django.test import TestCase

# Create your tests here.
class CITest(TestCase):
  def test_1(self):
    print('絶対に通るテスト')
    self.assertEqual(True, True)

pushして、GitHub Actions上でテストが実行されることを確認する

いよいよpushする。

$ git add .
$ git commit -m 'CI自動テストを追加'
$ git push origin feature/add_github_actions

その後、GitHubのリポジトリの、Actionsタブを開いてみると。。。

わいへい
わいへい

おお! 自動テストが実行されてる!!!

ウサギ
ウサギ

ついでにこのままプルリクエストを出してみると。。。

自動テストが通っている

直近のpushで自動テストが通っていることが分かる。

自動テストが通らなければプルリクをマージさせない、というブランチ戦略も可能だ。

テストが通らなければプルリクをマージさせない

Settings -> Branches -> 編集したいブランチのEditボタン押下 -> Require status checks to pass before merging を有効にして、buildを検索フィールドに入れると、設定可能。

意味のあるテストを実装してCIでテストを回してみよう

これまでのレッスンで色々な自動テストを作ってきたな。

試しに、UI操作の自動テストをする(E2Eテスト)をもう一度作ってみて、それをCIのテストで実行してみよう。

Seleniumを使ったE2Eテストの場合、ちょっと工夫が必要だ。

それは各自で考えてみてくれ。

念のため答えは下記ブランチに用意しておいた。どうしてもわからなかったら参照するといい。

GitHub - yheihei/base_diary at feature/#7-test-ui
ウサでも分かる中級Django講座の教材. Contribute to yheihei/base_diary development by creating an account on GitHub.

テスト自動化(CI)のまとめ

ウサギ
ウサギ

今回は、自動テストをGitHub Actions上で動かす方法を学んだな

わいへい
わいへい

.github/workflows/django.ymlファイルに、色々書き込んでいくんだったね

ウサギ
ウサギ

これでテストに関するレッスンは全て終わりだ

ウサギ
ウサギ

今のお前なら、大抵のテストは書けるようになっているはず

ウサギ
ウサギ

これを読んでくれた奇特な読者についても、

勉強しただけで終わらせるのではなく、

実際の現場でテストを書いてみてくれ

ウサギ
ウサギ

可能であればCIツールに自動テストを組み込み、

チーム全体にテストの有用性を伝えていってほしい

ウサギ
ウサギ

最後に、ここまで読んでテストに興味を持ってくれた皆に向けて、一つコラムを書いてみた

ウサギ
ウサギ

暇であれば斜め読みしてくれると助かる

ウサギ
ウサギ

それではいいテストライフを!

\ 講座で学んだことを即アウトプットしよう /

Djangoの基礎を学びたい方は

Djangoの基礎を固めたい方はこちら(セール時に買うのがおすすめ)

『Djangoパーフェクトマスター』〜インスタ映えを支えるPython超高速開発Webフレームワークを徹底解説!

動画講座で手を動かしながら、ほとんどのことが学べます。

ウサギもここから始めました。

コメント

タイトルとURLをコピーしました