静的解析だけでは、排除できないリスクもある

• ロジック自体の間違い

  • 特に、複雑なアルゴリズムやデータ構造の実装時

• 配列の範囲外参照

• 実行時エラーや想定しない挙動のリスクを放置していると

  • 上層でエラーが発生したときの原因調査の負担が大きくなる
  • コードを書くときの心配事が増え、開発スピードに悪影響を及ぼす
  • デモで壊れるかもしれない

Pytest

https://docs.pytest.org/en/7.1.x/getting-started.html

実際に使うロジックとは別に、テスト専用のスクリプトを定義

• 値や関数の入出力の正誤を、実際に動かして確かめることができる

ハッカソンでは網羅的に書く必要はないが、うまく活用する

• 複雑なロジックの場合、段階的にテストを書いて心配事をなくすことで、効率的に開発できることも多い
• テストを書きすぎると、その関数やクラスが柔軟に変更しにくくなる

使用例

# 間違った実装
def fibonacci(n: int) -> int:
    if n == 0:
        return 1
    if n == 1:
        return 1
    return fibonacci(n - 1) + fibonacci(n - 2)

print(fibonacci(8))