overhave
5.2.1
オーバーヘイブは、BDDのWebフレームワークです。フラスコ管理とPydanticに基づいた、スケーラブル、構成可能、使いやすいです。
PypiからPIP経由でオーバーヘイブをインストールできます。
pip install overhaveWeb-Interfaceは、BDD機能管理のための基本的なツールです。それは次のとおりです。
情報 - ツールまたはプロジェクトに関するオプションの情報があるインデックスページ。
機能、テストの実行、バージョン、タグ：
機能レコード管理のインターフェイスを提供し、ID、名前著者、時間、編集者、公開ステータスに関する情報を提供します。スクリプトパネルを介してアイテムを検索、編集、または削除することができます。
テスト実行管理用のインターフェイスを提供し、情報を提供します。
テスト実行に対応する機能バージョンが含まれています。バージョンには、リモートGITリポジトリへのPRリンクが含まれています。
機能のタグ付けに使用されるタグ値が含まれています。
テストユーザー - テストユーザーを表示および構成するためのセクション。
グループサブセクション。
（開発中）。
オーバーヘイブ機能は、機能編集モードの特別なスクリプトパネルを介して作成および/または編集できます。機能には、アプリケーション、一意の名前、従来の形式`PRJ-NUMBER` 、シナリオテキストを備えた指定されたタスクリストによって登録されているタイプが必要です。
スクリプトパネルには、インターフェイスの右側にpytest-bddステップテーブルがあります。これらの手順は、適切なフィクスチャモジュールで定義され、[スタートアップ]のアプリケーションで表示されるように登録する必要があります。
機能編集モードのオーバーヘイブスクリプトパネルの例
オーバーヘイブWebインターフェイスでのテストの実行後、Allureレポートを生成します。 Pytestを介して手動でテストを実行すると、これらの結果は、Arrure CLIツールを使用してAllureレポートに変換できます。このレポートには、機能で説明されているシナリオの説明が含まれています。
オーバーヘイブの機能を実行した後の生成されたアリュールレポートの例
オーバーヘイブには、特別なデモモード（開発中）があります。これは、フレームワークのデモンストレーションと手動のデバッグ /テストに使用できる可能性があります。フレームワークは、デバッグモードで簡単にサーバーを実行するためのCLIエントリポイントを提供します。
make up # start PostgreSQL database and Redis
overhave db create-all # create Overhave database schema
overhave-demo admin # start Overhave admin on port 8076 in debug mode
overhave-demo consumer -s test # start Overhave test execution consumer注：消費者は必要ない特別モードで管理者を実行できます。このモードでは、テストと公開タスクを非同期に実行するためにThreadPoolを使用します。
overhave-demo admin --threadpool --language=ruしかし、このThreadPoolモードはKubernetesのパラダイムでは避けられません。そのため、対応する消費者を正確に使用することを強くお勧めします。
オーバーヘイブには、サービスWebインターフェイスを開始し、コンシューマを実行し、基本的なデータベース操作を実行する簡単な方法を提供するCLIがあります。例は以下にあります：
overhave db create-all
overhave admin --port 8080
overhave consumer -s publication
overhave api -p 8000 -w 4注：Service Startingは一連の設定を使用するため、たとえば`OVERHAVE_DB_URL`など、プレフィックス`OVERHAVE_`を使用して仮想環境を介して設定できます。コンテキストインジェクションを介してより明示的な方法で設定を構成する場合は、ドキュメントの次の部分を参照してください。
サービスは、OverhaveContextオブジェクトの準備されたインスタンスを使用して、アプリケーションコンテキストインジェクションを介して構成できます。このコンテキストは、初期化された`ProxyFactory`インスタンスの`set_context`関数を使用して設定できます。
たとえば、 `my_custom_context`が準備されました。したがって、アプリケーションの起動は、フォローコードで実現できます。
from overhave import overhave_app , overhave_admin_factory
factory = overhave_admin_factory ()
factory . set_context ( my_custom_context )
overhave_app ( factory ). run ( host = 'localhost' , port = 8080 , debug = True )注記：
`overhave_app`既に有効になっている準備されたフラスコアプリケーションです`overhave_factory`は、オーバーヘイブのLRUキャッシュインスタンスの関数です`ProxyFactory` ;インスタンスは、 `overhave_app`で直接使用されるアプリケーションコンポーネントにアクセスできます。`my_custom_context`はコンテキスト構成の例ですオーバーヘイブには、Redisストリームに基づいたプロデューサー消費者アーキテクチャがあり、3つの消費者のタイプをサポートしています。
`overhave_test_execution_factory` ;`overhave_publication_factory` ;`overhave_emulation_factory` 。注： `overhave_test_execution_factory`には、コンテキストインジェクションの能力があり、 `overhave_admin_factory`としてカスタムコンテキストを豊かにすることができます。
オーバーヘイブ独自の特別なプロジェクト構造をサポートします。
適切なアプローチは、機能、フィクスチャー、ステップディレクトリを含むルートディレクトリ（現在のリポジトリ内の「デモ」など）を作成することです。
機能ディレクトリには、個別のディレクトリとしてさまざまな機能タイプが含まれており、それぞれが事前に定義されたPytest-BDDセットのステップに対応しています。
FIXTURESディレクトリには、さまざまな機能タイプによって分割された典型的なPytestモジュールが含まれています。これらのモジュールは、pytest-bdd分離テスト実行に使用されます。 Pytest-BDD Steps Collectionの特別なメカニズムのために必要です。
ステップディレクトリには、異なる機能タイプによって分割されたpytest-bddステップパッケージが含まれています。各ステップSubdirectoryには、サポートされている機能タイプに従って、独自の宣言されたステップがあります。
したがって、ユニークなステップとpytestフィクスチャーを使用して、さまざまな製品方向の独自の水平構造を作成することができます。
注：この構造は、オーバーヘイブアプリケーションで使用されます。フォームされたデータは、Web-Interfaceスクリプトパネルで登録機能タイプを指定する可能性を提供します。また、この構造は、スクリプトパネルの右側に表示される手順を定義します。
オーバーヘイブには、独自のアップデートを使用して、Pytest-BDDからGherkinを継承する独自の特別な機能のテキスト形式があります。
`@severity.blocker` ）;`PRJ-1234`のタスクトラッカーのチケット。記入された機能コンテンツの例は、feature_example.rstにあります。
カスタム追加情報を使用して、Pytestマーカーの使用法のソリューションをオーバーヘイブします。
例：
@disabled(not ready)
Feature : My business feature @disabled(TODO: https://tracker.myorg.com/browse/PRJ-333; deadline 01.01.25)
Scenario : Yet another business feature @xfail(bug: https://tracker.myorg.com/browse/PRJ-555)
Scenario outline: Other business feature理由がURLを含む場合、オーバーヘイブはAllureリンクをレポートに添付します。
オーバーヘイブには、魅力的なテストケースにおける独自の管理サービスへのリンクを設定する能力があります。 allureレポートを生成すると、リンクが自動的に設定されます。この関数は、環境のセットアップで有効にすることができます変数`OVERHAVE_ADMIN_URL` ：
export OVERHAVE_ADMIN_URL=https://overhave-admin.myorg.comまた、オーバーヘイブには、GITリポジトリにファイルを機能させるリンクを設定する機能があります。 allureレポートを生成すると、リンクが自動的に設定されます。この関数は、環境のセットアップで有効にすることができます変数`OVERHAVE_GIT_PROJECT_URL` ：
export OVERHAVE_GIT_PROJECT_URL=https://git.myorg.com/bdd-features-repoWeb -Interface言語はデフォルトでENGであり、切り替えることができませんでした（必要な場合は、 `feature request`を作成するか、自分自身を貢献してください）。
機能テキストとPytest-BDD BDDキーワードは、オーバーヘイブエクストラモデルで構成できます。たとえば、RUSキーワードはフレームワークで既に定義されており、使用可能に使用できます。
from overhave . extra import RUSSIAN_PREFIXES
language_settings = OverhaveLanguageSettings ( step_prefixes = RUSSIAN_PREFIXES )注：言語の独自のプレフィックス値マッピングを作成できます。
from overhave import StepPrefixesModel
GERMAN_PREFIXES = StepPrefixesModel (
FEATURE = "Merkmal:" ,
SCENARIO_OUTLINE = "Szenarioübersicht:" ,
SCENARIO = "Szenario:" ,
BACKGROUND = "Hintergrund:" ,
EXAMPLES = "Beispiele:" ,
EXAMPLES_VERTICAL = "Beispiele: Vertikal" ,
GIVEN = "Gegeben " ,
WHEN = "Wann " ,
THEN = "Dann " ,
AND = "Und " ,
BUT = "Aber " ,
)Overhaveは、BitbucketまたはGitlabがホストするリモートGitリポジトリに新機能または変更を送信する機能を提供します。 Bitbucketとの統合はネイティブですが、GitLabとの統合ではPython-Gitlabライブラリを使用します。
プロジェクトに必要な設定を設定できます。
publisher_settings = OverhaveGitlabPublisherSettings (
repository_id = '123' ,
default_target_branch_name = 'master' ,
)
client_settings = OverhaveGitlabClientSettings (
url = "https://gitlab.mycompany.com" ,
auth_token = os . environ . get ( "MY_GITLAB_AUTH_TOKEN" ),
)[Bitbucketの場合）またはマージRequest（gitlabの場合）をクリックすると作成されたマージレクエスト（gitlabの場合）テスト実行結果で[プル要求]を作成します。このボタンは、サクセステストランの結果にのみ使用できます。
注：GitLab API認証の最も人気のあるケースの1つは、サービスアカウントを備えたOAUTH2スキーマです。このスキーマによれば、OAUTH2トークンが必要です。これは短い寿命があり、環境を通じて指定できませんでした。この状況では、 Overhaveには、独自のTokenizerclientsettingsを使用して特別なTokenizerclientがあります。このシンプルなクライアントは、リモートカスタムGitLabトークネザーサービスからトークンを取得できます。
オーバーヘイブは、現在のGITリポジトリの状態をデータベースと同期させることができます。これは、データベースにある機能を更新できることを意味します。更新のソースはリポジトリです。
たとえば、GITリポジトリでバルクデータ交換を行う必要があり、これでリモートデータベースに変更を提供する必要があります。これはそれほど簡単ではありません。
プロジェクトに必要な設定を設定できます。
overhave sync run # only update existing features
overhave sync run --create-db-features # update + create new features
overhave sync run --pull-repository # pull git repo and run syncこのツールをオーバーヘイブデモモードでテストすることができます。デフォルトでは、3つの機能がデモデータベースに作成されます。それらを変更するか、新しい機能を作成して同期コマンドを実行してみてください。結果が表示されます。
overhave-demo sync-run # or with '--create-db-features'オーバーヘイブ既存の機能ファイルの検証をサポートします。コマンド機能を解析し、定義された機能情報形式を入力してみてください。問題がある場合、特別なエラーがスローされます。
overhave sync validate-features
overhave sync validate-features --raise-if-nullable-id
overhave sync validate-features --pull-repositoryそして、はい、あなたはデモモードでそれを試すことができます：
overhave-demo validate-features
overhave sync validate-features -r # --raise-if-nullable-idオーバーヘイブは、レンダリング用にカスタムindex.htmlファイルを設定する機能を提供します。ファイルへのパスは、環境を介して設定し、コンテキストで設定できます。
admin_settings = OverhaveAdminSettings (
index_template_path = "/path/to/index.html"
)オーバーヘイブは、 `AuthorizationStrategy`列挙で宣言されたいくつかの承認戦略を提供します。
適切な戦略と追加データを`OverhaveAuthorizationSettings`に配置する必要があります。たとえば、LDAP戦略は次のように構成できます。
auth_settings = OverhaveAuthorizationSettings ( auth_strategy = AuthorizationStrategy . LDAP )
ldap_manager_settings = OverhaveLdapManagerSettings ( ldap_admin_group = "admin" )オーバーヘイブバケットの作成や削除、ファイルのアップロード、ダウンロード、削除など、 S3クラウドの相互作用の機能を実装します。フレームワークは、リモートS3クラウドストレージにレポートやその他のファイルを保存する機能を提供します。次の設定で環境を豊かにすることができます。
OVERHAVE_S3_ENABLED=true
OVERHAVE_S3_URL=https://s3.example.com
OVERHAVE_S3_ACCESS_KEY= < MY_ACCESS_KEY >
OVERHAVE_S3_SECRET_KEY= < MY_SECRET_KEY >オプションで、デフォルト設定を変更することもできます。
OVERHAVE_S3_VERIFY=false
OVERHAVE_S3_AUTOCREATE_BUCKETS=true有効になっている`OVERHAVE_S3_AUTOCREATE_BUCKETS`フラグが可能になったフレームワークは、バケットが存在しない場合、リモートストレージにアプリケーションバケットを作成します。
オーバーヘイブには、Fastapiに基づいて、独自のアプリケーションプログラミングインターフェイスがあります。
swaggerを通してopenapi.jsonをオーバーヘイズします
現在の可能性は、組み込みのSwaggerを介して表示できます。APIを実行して、ブラウザでhttp：// localhost：8000を開きます。
overhave api -p 8000インターフェイスにはOAUTH2スキームを介して承認があるため、使用するには`OVERHAVE_API_AUTH_SECRET_KEY`をセットアップする必要があります。
現在、APIはリソースの種類を実装しています。
貢献は大歓迎です。
プロジェクトのインストールは非常に簡単で、準備されたコマンドが少なくなります（Ubuntuでのみ事前に作業を行います。したがって、OSに手動で同じパッケージをインストールできます）：
make pre-init
make initパッケージ管理は詩によって提供されます。
TOXでテストを実行できます。 Docker-Composeは、データベースなどの他のサービスの準備とサービングに使用されます。単純なテストとリナーの実行：
make up
make test
make lintファイルを作成して、便利なショートカットを発見してください。 Dockerコンテナでテストを実行することもできます。
make test-dockerプロジェクトドキュメントは、SphinxとSimple Makeコマンドを介して構築できます。
make build-docsデフォルトでは、ドキュメントはHTMLビルダーを使用して_buildディレクトリに構築されます。
GNU GPLV2ライセンスの条件に基づいて配布されます。
問題が発生した場合は、詳細な説明でセクションの問題でここに報告してください。
