答え。

適切なバージョン管理と自動テストの統合は、プロジェクトの現在の状態に対して検証が一致することを保証するために重要です。

問題の歴史

自動テストは当初、メインプロジェクトとは別に行われることが多く、互換性の問題や保守の問題を引き起こしていました。複数のブランチの開発、頻繁なソフトウェアおよびテストのリリースは、共通のバージョン管理システムの必要性を生み出しました。

問題

バージョン管理や整合性のある統合がないと、以下の問題が発生します：

解決策

現代のアプローチ：

# 一般的なアプローチ：
git checkout -b feature/new_login
# 機能とテストが一緒に開発・テストされる
# レビュー後、主ブランチに一緒にマージされる

特に重要なポイント：

トリッキーな質問。

テストをプロジェクトのコードとは別のリポジトリに保存することはできますか？

はいが、テストの最新性を保つのが難しく、手動での同期が必要であり、リリースやバグフィックスの際に何かを「忘れる」リスクがあります。

プルリクエスト作成時にテストは新機能をすぐにカバーする必要がありますか？

理想ははいですが、実際には最初のプルリクエストで MVP/主要なシナリオをカバーし、複雑なケースは別のタスクとして実施されることが多いです。重要なのは、重要な機能がすぐにカバーされることです。

コードのロールバックなしにテストの変更だけをロールバックすることは可能ですか？

テストとコードが同じブランチにある場合は、はい、リビジョンをロールバックできます。ただし、コードなしの「テストロールバック」は避ける方が良いです：これは検証の質を悪化させます。

自動テストの別リポジトリを持つプロジェクト。リリース後、プログラマーたちはテストを「忘れて」更新せず、テストは失敗し、非 актуальные チェックが通り、バグが本番環境で発生した。

利点：

欠点：

テストとプロジェクトコードが同じ git ブランチで管理されており、新しいプルリクエストがあるたびに追加されたコードのために自動テストが必ず更新されます。全ての変更がコードレビューと自動チェックを通過します。

利点：

欠点：