自動テストで品質を確保するために #Python3

自動テストと品質の確保と

自動テストをマメに書くようにしていますが、自動テストを全てpassしてもエラーが起こる時は起こりますよね
出典は忘れましたが、自動テストツールで行うテストは、テストではなくチェックリストの自動実行だと

この意見は一理あって、チェックリストに抜け漏れがあると、その分の品質は確保出来ない訳でして
ですが、有償でサービスを提供している側からすると気持ちよくそのサービスを使って欲しい訳でして、
どうすれば自動テストでより良い品質の確保が出きるのか考えてみました

自動テストでカバーできない点

これまで自動テストでは問題なかったけど、stagingやproduction環境に上げるとダメだったケースを考えてみると、

自動テストに抜け漏れがある
環境に依存する
この2つのケースが多かったように思われます

自動テストの抜け漏れがあるケースについては、何故抜け漏れが生じたかを考えてみると

時間がかかってテストサイクルに支障が出たのでコメントアウト等を行いそのままだった
自動テスト単体で完結しないため出来ない
純粋に忘れていたり漏れたりした
mainルーチンに含まれる不具合で、開発時にはテストしていなかった
ぐらいが思い当ります

どう対応したら良いか

条件網羅的なメソッドや関数単位での自動チェックは従来通りの自動テストツールで行います
そしてstagingやproductionでのpteテストやQA観点での検証に、mainルーチンの条件を網羅した自動テストを行えば良いのではと考えました
勿論、そのテストは開発者ではなく、QA担当やサービスの仕様を熟知する人に書いてもらうと

テストはBDD開発ツールで行います
pythonで使えそうなツールを探してみたところ、2つ見つかりました

書きっぷりはほぼ一緒のようですね
なお、Python BDD Framework Comparison – The Pros and Cons が大変参考になりましたので、気になる方はチェックしてみてください

単体テストをpytestで書いているので、pytest_bddを使うことにします

report.feature

Feature: MakeReport
  make report without no error(s)

  Scenario: Make Report
    Given Year: 2022, Month: 11
    Then Return True

test_report.py

from datetime import date

import pytest
from pytest_bdd import scenarios, given, then, parsers

import app


scenarios('report.feature')


@pytest.fixture
def target_year_month():
    return {"YearMonth": date.today().strftime("%Y%m")}


@given(parsers.parse("Year: {year}, Month: {month}"), target_fixture="target_year_month")
def set_param(year, month):
    return {"YearMonth": f"{year}{month}"}


@then(parsers.parse("Return {return_value}"), target_fixture="target_year_month")
def return_true(return_value, target_year_month):
    assert app.main(target_year_month) == return_value

ちょうど担当していた年月をパラメータに受けて、そのレポートファイルを出力するテストを書いてみました
(本来であれば、レポートファイルのコンテンツもチェックすべきですが、今回は割愛します)
シンプル過ぎますね...

着目したいのが、featureファイルの書きようです
業務が分かっていて、少しシステムが分かっていれば、その人にfeatureファイルを書いてもらえば、
上述の「純粋に忘れていたり漏れたりした」のは防げるのではということです
そして上にあげた2点もクリア出来ますね

自動テスト単体で完結しないため出来ない
mainルーチンに含まれる不具合で、開発時にはテストしていなかった

「時間がかかってテストサイクルに支障が出たのでコメントアウト等を行いそのままだった」
こちらもこのBDD開発ツールでのテストを行うと必然的にクリアできます

今後の取り組み

現在私が関わっているシステムでは、ブラックボックスでテスト設計してくれるメンバーと
そのテストを実施してくれるメンバーがいます
ですが、システムの内部仕様まで意識したテストをする体制にはなっていません
QA的な体制を組むのはこれからですね

チームメンバー全員でワイワイとfeatureファイルを書きながら、何故このテストが必要なのかを皆で相談してチーム全員でテストを楽しめれば良いなと妄想しています