Yii、継続的インテグレーション-すべてを壊さない方法

多くの場合、アーキテクチャ、コード、パフォーマンスを実験します。 常に新しい機能を追加します。 Yiiを徐々に「アーキテクチャ」レイヤーと関連付けます-シャーディング、一時的にアクセスできないデータ、さまざまなキャッシュなどを操作します。 はい、私たちの仕事の成果は、完成するとオープンソースに行きます。



継続的インテグレーション（CI）の目標はテストではありません。 CIのタスクは、リファクタリング、新しい機能の追加、アーキテクチャの変更による破壊的な変更から自身を保護することです。 また、「不正なコード」、頻繁に繰り返されるバグ、「不正な」マージに対しても防御します。



CIには、DebianのJenkinsを使用しています。 CIスキャンに12時間を費やしました-完全に動作するまで。 CIのサポートに1日1分も費やしていません。あらゆる小さなことのテストを書いたり、TDDを練習したりしません。 ただし、CIは機能し、愚かな間違いから私たちを救います。



「注意しましょう」/「間違えないように」-私は開発者に呼びかけましたが、これは一時的にしか役に立たず、その後は100％にはなりませんでした。 人々は間違いをする傾向があり、忘れ、間違いを犯します。 いいえ、私はWebプロジェクトの「銀の弾丸」やYiiの小さな弾丸さえも発明しませんでした-アプリケーションを安定させる方法を見つけました。 あなたのアプリケーションは私のものとは異なり、私の方法はあなたにとってうまくいかないかもしれませんし、そうすべきではありません-私の方法があなたのために働くなら、私はあなたのアプリケーションのためにそれをしませんでした。 しかし、このようなCIのアイデアはどこでも機能します。 ただのアイデア。

アイデアは何ですか

1日あたりのテストにN時間を費やすことなく、アプリケーションの「フォールオフ」機能について回帰的にチェックするという考え方です。 これを実現するのは簡単です-「抽象エンティティ」に対して1つのテストを記述する場合、テストはすべての「具体的な」実装で合格する必要があります。 コードを標準化する-その異なる部分をいくつかの抽象化、たとえば3つの実装にすると、コード全体を3つのチェックでカバーできます。 はい、テストではなく「チェック」を使用します-機能をテストせず、「コードが機能し、クラッシュせず、致命的ではない」ことを確認します。 適切なコードを使用すると、致命的なエラーを引き起こさないようにビジネスロジックが壊れることはほとんどありません。 少なくとも私たちと。 このようなコードを作成しようとします-ロジックが正しく機能する場合-機能しない場合は機能する-FatalExceptionがスローされるか、その他の致命的なエラーが発生します。 この「ハード」な方法が正しいと思う そうしないと、壊れたロジックを探すのが非常に困難になります。



コードを次の抽象概念に標準化しました：モデル（Yiiではすでにかなり標準であり、find、save、deleteメソッドとの非常に明確なインターフェースを持っています）。 コントローラー（これも非常に標準的です）、アクション（アクション）、コンポーネント、ライブラリー。



モデルがすべてシンプルな場合、コントローラーとアクションゲームをいじる必要がありました。 外部呼び出し（http、コンソール）は致命的なエラー（http> = 500）を引き起こさないことを決定しました：エンティティは404、曲線要求は400、アクセス403を意味します。存在しないIDまたは他のいくつかの不正なパラメータ-これは、httpプロトコルの観点から見ると不正な動作です-ユーザーエラーは5xxではなく4xxです-不正なリクエストで致命的になる必要はありません。



実際、コントローラーのチェックはこの原則に基づいて行われました-モジュール、コントローラーを作成し、アクションをプルします-何が起こったのかを確認します-ExceptionPage404-これは正常です（データを$ _GETに渡さなかった）が、FatalExceptionまたはPHPエラーが既に悪い場合-テスト合格しませんでした。



また、作成したYiiのコンポーネントも標準化しました。 この場合、コンポーネントは既存のYii機能の拡張です。 たとえば、シャーディングの追加、グローバルデータベースキャッシュ。 このような関数は、Yiiモデルと拡張コンポーネントという2つの抽象化を同時に実装します。 また、2回チェックされます-すべてのモデルの例で、コンポーネントとして個別に。



ライブラリ-これは、Yiiとは関係なく、私たちが作成した完全に「左」の機能ですが、ロジックの特別なケースのみを実装しています。ほとんどの場合、サービス指向アーキテクチャの他のサービスとの相互作用です。 それらのチェックとテストは別の記事のトピックです。1つだけ言います。CIでそれらを個別のプロジェクトとしてテストし、メインアプリケーション内で「統合テスト」を生成します。

例での実装

4つの組み立て手順があります。

• 依存関係の展開、移行、インストール/更新-それは上記のアイデアとは関係ありません。
• コード品質チェック
• インターフェイスコードの検証-上記のアイデアの実装。
• 頻繁にポップアップするバグの少数の単体テスト（phpunitとselenium + phpunitの両方）。 非常にまれに「サポート」または追加されることはないため、「テストに1日N時間を費やさないでください」と書きました。

ステップ1-デプロイ

このチェックは、2つのバージョンで実行されます-前のバージョンからの移行（本番の現在の状態と同じ）とゼロからのスキャン（仮想マシンの自動インストール、自動パペット構成、アプリケーションおよびベーススキャン）

具体的なことは言いません、なぜなら これはこの記事とまったく異なる話には当てはまりません。

ステップ2-コード品質

最初に確認するのは、「php -l」-すべてが解析されるかどうか-これなしでは意味がありません。 コードで2番目に探しているのは、禁止された呼び出し、die、var_dump、ini_set、exitです。 次に、通常のfgrepを使用して、曲がったマージの結果を探します。「<<<<<<<」、「>>>>>>」、「======」-秘密の場所を手で持っていると、このようなゴミがスキップされることがあります気づかず、競合を解決しませんでした。

また、正規表現を使用して以下を探します。

• コードの長い画面のメソッド。
• 「5つのネストされたif」のようなネストされたコード
• print（preg_replace（ '/ @ /'、“ /％/”、“ a” .substr（1、5、$ lala）。（Int）（bool）$ d））という形式の「ロードされたコード」。 -読むのが難しく、書くのが難しく、そのようなコードを見たくありません。

ステップ3-インターフェイスコードの検証

モデル、コントローラー、コンポーネント、ユニバーサルセレンチェック（はい、1つもあります！後で説明します）、ライブラリとの統合テストなど、いくつかの「ステップ」に分かれています。



最も簡単で最も興味深いものについて詳しく説明します。 最も単純なのはモデルです。

モデルはすべて保存、選択、削除する必要があります。 存在するのはこのためです。 特にこのテストでは、「デフォルトの有効なモデル」を作成する各モデルに静的メソッドを追加しました。これは、検証、データベースからの作成、保存、削除が可能なモデルです。

実際、このようなモデルを作成するために250のモデルに250のメソッドを記述していません。 親を使用して1つのメソッドを作成しました。ルールから検証パラメーターを抽出し、フィールドに有効な値を入力します。 私はそれに2時間を費やしました。



その結果、ループ内の各モデルに対して、次のようなことを行います。

$model = ModelClass::createDefault(); //   $this->assertNotNull($model); //? $this->assertTrue($model->save()); //? $pk = $model->getPk(); // primary key $loaded = ModelClass::model()->findByPk($pk); //    primary key $this->assertNotNull($loaded); //? $this->assertTrue($model->delete()); //? $this->assertIsNull(ModelClass::model()->findByPk($pk)); //?
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このトリッキーなテストで次のことを行いました：シャーディングレイヤーが機能していること、データベースキャッシュが通常の操作に干渉しないこと、データベース内のテーブルが正常に移行されていること、このモデルがこのテーブルに保存されていることを確認しました（+トリガーは落ちません）。



最も興味深いのは、セレンのチェックです。

私たちはインターフェースを研究し、楽しい結論に達しました-それは完全に標準化されています。 ユーザーインタラクションには4つの主なオプションがあります。

• グローバルページを変更
• タブ変更
• ダイアログボックスを開く
• ダイアログボックスでフォームを送信する

最初の3つのポイントは非常に簡単に自動化されました-グローバルページを変更するAおよびButtonタグにはグローバルcssクラスがあり、変更タブにはdata-tab属性があり、開始ダイアログにはdata-msgbox属性があります。 ページを変更する（ボタンを愚かにクリックする）、タブを変更する（ボタンを押す）、ダイアログを開く（クリックするだけ）、3つのネストされたループを作成するだけで十分でした。 ネストされた各段階で、ページのコンテンツが変更されたかどうか、divのコンテンツがタブに対して変更されたかどうか、またはダイアログが開いたかどうかを確認します。 途中で、ブラウザからjsエラーを収集します。

フォームでは、少し面倒でした。 可能性のある有効なデータの値を持つデータ型属性をフォーム要素に追加する必要がありました-data-type =“ email”、“ anyString”、“ checkboxChecked”、“ phone”、“ anyFile”など。 そしてそこに行きます！ フォームは標準化されており、すべての入力に共通のインターフェイスがあります-有効な電子メールが入力されたフィールドでは、電子メールに入力し、電話が入力されたフィールドでは-電話など、すべてのフィールドにあります。 フォームを送信し、エラーなしでダイアログが閉じることを確認します-これはデータが保存されたことを意味します。 次に、無効なデータを使用して同じことを繰り返します。たとえば、電話を書くメールフィールドに-フォームが送信されていないこと、およびユーザーにエラーが表示されていることを確認します。

フォームフィールドに属性を追加するのに約1.5時間かかりました。 そして、私たちにはいくつかの形式がありません-それは単純な仕事であり、あなたが座ってそれを行うならば、それは長くかかりません。



この単純な（またはトリッキーな）メソッドを使用して、サブジェクトのUI全体をチェックしました。

• ページ、タブ、ウィンドウを開くと致命的
• 有効および無効なフォームを送信すると致命的。
• 有効なデータとともに保存されるフォーム
• そのフォームは、無効なデータでエラーを出します。

単体テストとセレンテスト

正直なところ、ほとんどありません。 繰り返し発生するバグが発生した場合にのみ、それらを追加します。テスターは「まあ、それは再び機能しません！」と言いました。

古い書面のテストを変更することはありません-後方互換性を考慮してアプリケーションを開発します。 これはテストのためだけでなく、アプリケーションには携帯電話/デスクトップ用のAPIがあり、下位互換性が必要です。

それでは、次は何ですか？

少し後に、jsコードを標準化してカバーしました（testit同志titulusdesiderioに感謝します-nodejsから実行するように適合させ、そこでjsをテストします）

後で、css + html組版テストについて説明しました-曲率の問題について、diff-screenshotsを使用して、折りたたまれた組版をチェックしました。

もちろん興味がある場合は、これらすべてについて個別に説明します。



PS 「これはテストではありません」、「機能の5％をカバーする」などのフレーズでscる前に、テストしません。 まさにパフォーマンスチェックを行っています。

店内でライトが点灯していることを確認するようなものです。その熱をチェックせず、放出された光を測定せず、間違ったカートリッジにねじ込もうとしないで、点灯していることを確認するだけです。 コードでも同じことを行います。 シンプルでサポートなしの方法。



UPD。 ここで説明する実装例は単なる例であり、それ以上のものではありません。 主なものは、システムの一部である個々のエンティティを標準化するという考え方です。 標準の「ナッツ」は1つの方法で確認できますが、非標準の場合は別の方法を考え出す必要があります。