Cucumber Testingとは？フレームワーク、ツール、使い方を解説

はじめに

Cucumber Testingをご存知ですか？これは、ソフトウェアテストをよりユーザーフレンドリーにし、技術的なハードルを下げる画期的なツールです。

Cucumber Testingとは何でしょうか？簡単に言えば、開発者だけでなく、誰もが理解できる形で自動テストを作成・実行できるツールです。技術に詳しくない方にもわかるように、ソフトウェアの振る舞いを説明するイメージです。

Cucumber Testingは振る舞い駆動開発（BDD）のヒーロー的存在です。BDDは開発者、テスター、ビジネス担当者全員が同じ認識を持つことを目指しています。Cucumberはそのための「翻訳者」として、複雑な技術的な言葉を平易な日本語（または任意の言語）に変換する役割を果たします。

Cucumberが使う特別な言語は「Gherkin」と呼ばれます。Gherkinはテストをストーリーのように書ける記法です。「Given ホームページにいる、When ログインボタンをクリックする、Then プロフィールが表示される」というようにシンプルに書けます。

しかしCucumberはテストを読みやすくするだけではありません。ソフトウェアが何をすべきか（ビジネス要件）と、実際にどう動くか（コード）の橋渡し役でもあります。ビジネスと技術の両方の言語に堪能な翻訳者のようなものです。

BDDプロセスにCucumberを使うことで、単にテストを書くだけでなく、ソフトウェアがどう動くべきかについての共通理解を作り出すことができます。技術的な知識に関係なく、誰もが追えるロードマップを作るようなものです。

もし誤解や果てしない要件確認会議、開発者しか解読できないテストにうんざりしているなら、Cucumber Testingは開発プロセスに必要な新鮮なアプローチかもしれません。

BDD vs. TDD: 何が違うの？

「これはテスト駆動開発の別バージョンではないか？」と思われるかもしれません。BDD（振る舞い駆動開発）とTDD（テスト駆動開発）はソフトウェアテストのファミリーにおいてよく似ていますが、明確な違いがあります。

TDDは、開発者がまずテストを書いてから機能コードを書き始める手法です。設計図を先に書いて、それに合わせて家を建てるようなイメージです。ただし、その設計図（テスト）はコードで書かれており、全員が読めるわけではありません。

BDDはコラボレーションを中心に置きます。コード中心のテストではなく、開発者、テスター、ビジネス担当者全員が読めるシナリオを平易な言語で書きます。機能が「どうあるべきか」についての会話を、読みやすい「Given-When-Then」形式のストーリーに変換する翻訳者の役割を果たします。

TDDはコードが正しく動くかを行ごとに確認することに集中します。
BDDはズームアウトして、アプリケーション全体がユーザーの視点からどう振る舞うべきかに焦点を当てます。

つまり、TDDは「このコードは意図した通りに動くか？」を問い、BDDは「この機能は皆が期待する通りに振る舞うか？」を問います。個々のユニットの狭い視点から、チーム全員の認識を合わせる大きな絵へのシフトです。

Cucumberフレームワークを理解する

Cucumberの中核はサンドイッチのようなもので、複数の層が協力して機能します。主な構成要素はGherkinとStep Definitionsの2つです。

Gherkin：Cucumberのいわばソースとなるもので、Given、When、Thenといったキーワードを使うシンプルな言語です。「Given パンがある、When ピーナッツバターとジェリーを塗る、Then サンドイッチができる」というようにシンプルです。

Step Definitions：GherkinシナリオをコードとしてHTML上で実際に動かすものです。レシピに基づいてサンドイッチを実際に作る手のようなものです。

CucumberにおけるBDDライフサイクル：どう機能するか

Cucumberが明快さを重視していることはわかりましたが、BDDライフサイクルがCucumberフレームワーク内でどのように展開するか見ていきましょう。

開発者、テスター、マーケティング担当者まで、全員がバトンを持てるリレー競走を想像してください。一般的な流れは次のとおりです。

発見とコラボレーション：
まず会話から始まります。チームがブレインストーミングを行い、ソフトウェアの望ましい機能や振る舞いについて話し合います。これは一方的な会話ではなく、開発者、テスター、ビジネス担当者全員が「完了」の意味を定義するために意見を出し合います。
Gherkinでシナリオを書く：
次に、それらのアイデアをGherkinを使ってわかりやすいシナリオに変換します。ユーザーの視点からソフトウェアがどう振る舞うべきかについての小さなストーリーを書くようなものです。専門用語も略語も使わず、平易で人間にやさしい言語を使います。
Step Definitionsで自動化する：
ストーリーを書いたら、それを実際のコードに接続する時です。開発者はStep Definitionsを書きます。各GherkinステップをアプリケーションF上で実際に動かす「手順書」のようなものです。
テストの実行：
いよいよ楽しい部分です！Cucumberテストを実行して、ドキュメントが生き生きと動くのを見てください。何か問題が起きたとき、事前に共有された認識のおかげで原因を簡単に特定（そして修正）できます。
フィードバックとイテレーション：
最後に一緒に結果をレビューします。ビジネス目標と振る舞いが一致していましたか？変更が必要ですか？シナリオを微調整して繰り返します。全員が最新情報を把握しながら、継続的に改善していきます。

CucumberにおけるBDDライフサイクルは単なる技術的プロセスではありません。ソフトウェアをスムーズに動かし続け、チームが同じ方向に進むための継続的な会話とコラボレーションです。

Cucumberの魅力的な特徴：主な機能

言語を選べる：Java、Ruby、.NETなど、様々な言語をサポートしています。
主要ツールとの統合：Selenium、Appium、Watirなどの人気自動化フレームワークと連携し、Ruby on RailsやSpringでも動作します。Webアプリ、モバイルアプリ、クロスブラウザテストの自動化に適しています。
誰でも読める：Gherkin構文により、テストケースは平易な日本語（または任意の言語）で書かれます。開発者からビジネスアナリストまで、誰でもコードを理解しなくてもシナリオを読み書きできます。
コミュニケーションギャップを埋める：要件、テストケース、実装を同期させることで、チームが連携しやすくなり、「それはどういう意味？」という場面が減ります。
クロスプラットフォームの柔軟性：Java、.NET、Rubyなど、様々なソフトウェアスタックに適応できます。
ライブドキュメントをサポート：テストシナリオがアプリケーションの最新仕様書としても機能します。古い要件ドキュメントが影を潜めることはありません。
CI/CDとの簡単な統合：お気に入りの継続的インテグレーション・デプロイメントパイプラインとうまく連携し、本番環境に到達する前にバグを検出します。

Cucumberはチーム全員を積極的に参加させ、テストを読みやすくし、自動化を柔軟にするための機能を提供します。誰もがテーブルに着ける場を作ります。

Cucumberを使う場面

では、いつCucumberをツールキットから取り出すべきでしょうか？以下に最適なシナリオを挙げます。

チームが話し合う必要がある場合：開発者、テスター、ビジネス担当者が同じ認識を持つ必要があるプロジェクトに最適です。プロジェクト要件のための共通言語を持つようなものです。
明確なニーズを持つ複雑なプロジェクト：大規模で複雑な開発をしているが、何をすべきかは明確な場合、Cucumberは全員のビジョンを一致させるのに役立ちます。詳細な設計図で誰でも読めるものを持つようなものです。
陳腐化しないドキュメントが必要な場合：古いドキュメントにうんざりしていますか？Cucumberのテストはコードとともに最新の状態に保たれるライブな仕様書として機能します。自己更新するユーザーマニュアルを持つようなものです。
エンドツーエンドテストが必要な場合：システム全体を最初から最後までテストする必要がある場合、Cucumberはリアルな使用シナリオを模倣した包括的なテストシナリオを作成するのに優れています。

Cucumberはただのテストツールではありません。コミュニケーションの強力な基盤です。ギャップを埋め、要件を明確にし、全員の認識を合わせます。次にプロジェクトを始めるとき「どうすれば全員が同じ認識を持てるか？」と思ったら、Cucumberを試してみてください。チームに必要な新鮮なアプローチになるかもしれません。

Cucumber Testingをはじめる

BDDとGherkinの基本を理解する

始める前に、振る舞い駆動開発（BDD）とGherkinに慣れましょう。BDDはソフトウェアがどう振る舞うべきかをストーリーとして語ることです。Gherkinはそのストーリーを語るための言語です。

Gherkinはシンプルなキーワードを使います。

Feature：テストしている全体像
Scenario：テストしている特定の状況
Given：開始点
When：実行するアクション
Then：期待される結果

例えば：ソフトウェアのレシピを書くようなシンプルさです。

プログラミング言語を選ぶ

Cucumberは多くの言語と相性が良いです。Java、Ruby、JavaScriptなど、チームが最も使いやすい言語を選びましょう。Javaが好きなら、Cucumberとの相性はピカイチです。

環境のセットアップ

舞台を整える時間です。

IDEを選ぶ（IntelliJ IDEAとEclipseが人気です）
Cucumberをインストールする（JavaならMaven、RubyならRubyGemsを使用）
プロジェクト構造を設定する（featuresフォルダとstep definitionsフォルダを別々に作成）

少し技術的に見えても心配いりません。各ステップをガイドしてくれるチュートリアルはたくさんあります。

Feature FileとStep Definitionsを作成する

いよいよ楽しい部分です。

Feature files：

.feature拡張子で新しいファイルを作成する
Gherkinでシナリオを書く

Step definitions：

Step definitionsの新しいファイルを作成する
シナリオの各ステップに一致するメソッドを書く

これで最初のCucumberテストが完成です。LEGOで遊ぶように、基礎から始めて、気づけば複雑な構造を作れるようになります。

まずはシンプルから始めることが重要です。1つのシナリオを書いて、そのステップを実装し、そこから積み上げていきましょう。すぐにCucumberのプロになり、チーム全員が理解・評価できるテストを作れるようになります。

覚えておきたい制限事項

Cucumberの旅がスムーズに聞こえるとしても、全速力で進む前に道中のいくつかのでこぼこを知っておくといいでしょう。

TDDの知識があると役立つ：テスト駆動開発（TDD）の基礎知識があると、BDDとCucumberの習得がずっと楽になります。テストを書くのが全く初めてなら、学習曲線が少し急に感じるかもしれません。
しっかりした要件が必須：BDDは要件が明確でよく分析されている場合に最も効果的です。要件があいまいだったり常に変わったりすると、テストシナリオがすぐに時代遅れになったり効果がなくなったりします。
技術スキルが必要：GherkinはCucumberによって読みやすく設計されていますが、Step Definitionsの実装にはある程度の技術力が必要です。シンプルから始めてスキルを伸ばしていくことで、大きな成長が期待できます。

Cucumberテストを構築し始める際は、これらの考慮事項を念頭に置いてください。少しの計画がBDDの冒険をできるだけスムーズにするために大いに役立ちます。

効率的なBDDのためのCucumberベストプラクティス

CucumberテストをグッドからグレートにするためのTIPSをご紹介します。

シナリオを短く焦点を絞る：明確さを目指しましょう。各シナリオは1つのアイデアやユーザーの旅をテストすべきです。
ステップを賢く再利用する：「Given ログインページにいる」を何度も書いているなら、それでOKです！再利用可能なステップは時間を節約し、メンテナンスを楽にします。
技術用語を避ける：ビジネスに優しい言語でステップを書きましょう。プロダクトマネージャーが理解できなければ、書き直しが必要です。
Step DefinitionsをDRYに保つ：重複するStep Definitionsは混乱を招きます。IntelliJ IDEAやVisual Studio Codeなどのツールで重複を見つけましょう。
Feature Filesを論理的に整理する：機能、モジュール、ユーザーペルソナごとに関連シナリオをまとめましょう。本棚を整理するようなもので、カテゴリがあると見つけやすくなります。
定期的にレビューする：古いFeature Filesにはバグが潜みます。テストが最新の要件を反映していることを確認するために定期的なレビュー時間を設けましょう。
チーム間でコラボレーションする：一人でやらず、テスター、開発者、ビジネスアナリストを参加させましょう。Cucumberは全員の声が聞かれるときに最大の効果を発揮します。

これらのプラクティスを守れば、Cucumberを使ったBDDの旅がずっとスムーズになり、エンドツーエンドテストに費やせる時間が増え、混乱した古いスクリプトを解きほぐす時間が減ります。

CucumberとSeleniumの統合：テストに命を吹き込む

自動化テストにCucumberとSeleniumをどのように組み合わせるのでしょうか？Cucumberはテストケースを平易な英語で説明することに優れていますが、実際にブラウザを操作してボタンをクリックするには、Seleniumが必要です。統合プロセスは初心者にも取り組みやすいものです。

組み合わせた場合の流れ：

GherkinのFeature Files：通常のCucumberテストと同様にGherkinでテストシナリオを書きます。これらの「ストーリー」はアプリケーションに何をしてほしいかを概説します。
SeleniumコマンドによるStep Definitions：各GherkinステップはコードにマッピングされCucumberここでSeleniumが登場します。Step definitionファイルでは、ページを開いたり、フォームに入力したり、テキストを確認するなどのアクションを実行するSeleniumコードを書きます。
テストの実行：お気に入りのIDEやコマンドラインツールでテストを起動します。Cucumberがストーリーを指揮し、Seleniumがブラウザを動かします。

なぜ組み合わせるのか？
この強力なコンビにより、様々なブラウザで自動テストができ、開発者からプロジェクトマネージャーまでチーム全員にとって読みやすいシナリオを維持できます。Chrome、Firefox、Safariでテストしたいですか？Seleniumが対応します。Cucumberにより、テストケースは常に最新のドキュメントとしても機能します。

成功のためのクイックTIPS：

Feature files、Step definitions、Page objectsを別々のフォルダに整理する。
Gherkinは読みやすく保ち、技術的な部分はSeleniumに任せる。
自動化されたCucumber-Seleniumテストはローカルで実行することも、より多くのデバイスとブラウザに対応するためにクラウドベースのサービスに規模を拡大することもできます。

CucumberとSeleniumを組み合わせることで、チームの連携を保ちドキュメントを最新に保ちながら、平易な言語のシナリオを堅牢なブラウザ駆動の現実に変えることができます。

Cucumber Testingの種類

主な自動化テストフレームワークの種類

Cucumberに深く入る前に、自動化テストフレームワークの世界全体を見渡してみましょう。それぞれ独自のスタイルがあります。

線形スクリプティング：「速くて単純」なアプローチです。一方向の旅程を作るようなもので、セットアップは速いですが、旅の計画が変わると変更が難しくなります。
モジュラーフレームワーク：テストを再利用可能なブロックに分解します。LEGOの街を作るようなもので、プロジェクトが成長するにつれてピースを入れ替えやすいです。
データ駆動テスト：スプレッドシートが好きな方に最適です。テストロジックはコードに、テストデータは別のファイル（ExcelやCSV）に置きます。異なる入力で同じテストを繰り返すのに最適です。
キーワード駆動フレームワーク：異なるコーディングスキルレベルのテスターが多い場合に最適です。「クリック」「ログイン」「検索」などのキーワードを使ってテストを作り、ほぼ指示書のように読めます。
振る舞い駆動開発（BDD）：ここでCucumberが輝きます。BDDフレームワークは開発者、ビジネス担当者、テスター全員を誘い、平易な英語でテストを書きます。

各フレームワークには得意な場面があります。最適なものはチームのスキル、プロジェクトの要求、どれだけの柔軟性とコラボレーションが必要かによって異なります。

機能テスト：基本

機能テストは、ソフトウェアの各機能が仕様通りに動作することを検証します。Cucumberテストの基本です。Cucumberを使うと各機能を平易な言語で説明でき、技術的でないステークホルダーもテストプロセスを理解・貢献できます。このタイプのテストにより、アプリケーションがユーザーの視点から意図した通りに動くことを確認できます。

回帰テスト：予期しない変化を防ぐ

回帰テストはあなたのセーフティネットです。ソフトウェアへの新しい変更や追加が既存の機能を壊していないことを確認します。Cucumberはここで特に優れています。変更のたびに全テストスイートを簡単に再実行できます。意図しない副作用を素早く検出できます。変更が頻繁なアジャイル環境で特に役立ちます。

エンドツーエンドテスト：完全なユーザー旅

エンドツーエンド（E2E）テストをCucumberで行うことで、最初から最後まで実際のユーザーシナリオをシミュレートできます。アプリケーションのフローをリアルな状況でユーザーが体験するようにテストします。Cucumberのナラティブスタイルはこれらの複雑な多段階プロセスを説明するのに最適です。E2Eテストは複数の機能をカバーし、外部インターフェースやサービスとのやり取りを含むことがよくあります。

なぜ実際のブラウザとデバイスが重要なのか

なぜシミュレーターではなく実際の条件でCucumberテストを実行するのでしょうか？実際のブラウザやデバイスでテストすることで、ユーザーが実際に見るものを正確に確認できます。シミュレーターでは見逃してしまう可能性のある、デバイス固有のバグを本番環境に届く前に潰せます。

統合テスト：調和を確保する

統合テストは、アプリケーションの異なるコンポーネントやサービスが期待通りに連携することを検証します。Cucumberを使うと、様々な部分が相互作用する際の期待される振る舞いを説明できます。ユニットテストでは現れないが、コンポーネントを組み合わせると出てくる問題を検出するために重要です。マイクロサービスアーキテクチャやサードパーティ統合を扱う際に特に価値があります。

受け入れテスト：ビジネスニーズを満たす

受け入れテストは、ソフトウェアがビジネス要件を満たし、デリバリーの準備ができているかを検証します。Cucumberのスタイルはここで特に輝きます。Gherkin構文により、ビジネスアナリストやステークホルダーが自分たちの言葉で受け入れ基準を書けます。その基準が直接自動テストに変換され、デリバリーされるものが要求されたものと一致することを確認できます。

これらの各テストタイプは、ソフトウェア開発ライフサイクルにおいてユニークな目的を果たします。Cucumberの魅力は汎用性にあります。これらすべての異なるタイプのテストに同じツールと構文を使えます。この一貫性により、チームが包括的なテスト戦略を採用・維持しやすくなります。

Cucumberのアプローチは、テストプロセス全体を通じて開発者、テスター、ビジネスステークホルダー間のコラボレーションを促します。共通言語を使うことで、チームは誤解を減らし、開発サイクルの早い段階で潜在的な問題を検出できます。

Cucumberテストを成功させる鍵は、シンプルから始めて徐々にテストスイートを構築していくことです。一度にすべてのタイプのテストを実装する必要はありません。アプリケーションの最も重要な領域から始めて、時間をかけてカバレッジを拡大しましょう。このアプローチにより、テストスイートの複雑さを管理しながらCucumberテストの恩恵を受けられます。

Cucumber Testingの利点

A. コミュニケーションギャップを埋める

Cucumberの最大の強みは、技術チームと非技術チームのコミュニケーションを改善できる能力です。

ビジネスアナリストが平易な英語でシナリオを書ける
開発者が「翻訳」に迷うことなくこれらのシナリオを実装できる
マネージャーがコードを見ることなくテストカバレッジを簡単に理解できる

この共通言語によりコラボレーションが促され、全員がソフトウェアが何をすべきかについて同じ認識を持てます。

B. クリアなテスト仕様

CucumberのGherkin構文は明確で読みやすいテスト仕様を書くためのゲームチェンジャーです。

テストは自然言語のように読め、誰にでもアクセスしやすい
Given-When-Then形式が各シナリオに明確な構造を提供する
複雑な振る舞いを理解しやすいステップに分解できる

この明確さは誤解を早期に発見し、テストケースのレビューと検証を容易にします。

C. 二役をこなすドキュメント

Cucumberを使うと、テストは単なるテストではなく、ライブドキュメントになります。

シナリオが実行可能なテストと読める仕様書の両方として機能する
ドキュメントがテストプロセスの一部であるため常に最新状態を保つ
新しいチームメンバーがシナリオを使ってシステムの振る舞いを素早く理解できる

この二役のアプローチにより時間が節約され、ドキュメントが常にソフトウェアの現在の状態を反映することが保証されます。

D. 振る舞い駆動開発の限界

あらゆる方法論と同様に、BDDにもチームが対処すべき課題があります。

スキルと経験の要件：BDDはチームメンバーがTDDなどの技術的プラクティスに精通している場合に最もうまく機能します。テストが全く初めての場合、概念が最初は少し困難に感じるかもしれません。
明確な要件への依存：BDDの効果は明確でよく分析された要件があることに大きく依存します。最初の要件があいまいだったり不完全だったりすると、シナリオとテストが軌道を外れやすくなります。
技術的な熟練度：BDDはテストをよりアクセスしやすくすることを目指していますが、チームメンバーはビジネスドメインと技術ツールの両方をある程度把握している必要があります。
オーバーヘッドの可能性：詳細なシナリオを書くことは時間がかかり、要件が変わるにつれてそれらを維持することは追加のオーバーヘッドをもたらす可能性があります。

これらの限界を事前に理解することで、チームはよりスムーズな採用を計画し、BDDプラクティスを最大限に活用できます。

よくある課題

A. 学習曲線

他の新しいツールと同様に、Cucumberには学習曲線があります。

チームメンバーがGherkin構文を習得する必要がある
開発者はStep Definitionsの実装方法を理解しなければならない
シナリオの適切な詳細レベルを見つけるには練習が必要

ただし、学習への初期投資は、コラボレーションの改善とより明確なテストプロセスとして報われます。

B. シナリオ作成への時間投資

Cucumberシナリオの作成・維持には時間がかかります。

明確で包括的なシナリオを書くには思考と努力が必要
ソフトウェアが進化するにつれ、シナリオを更新する必要がある
カバレッジとメンテナンスのオーバーヘッドのバランスが必要

重要な機能に焦点を当て、時間をかけてテストスイートを構築することが鍵です。

C. 既存プロジェクトへの統合

確立されたプロジェクトにCucumberを導入することは難しい場合があります。

既存のコードベースがCucumberとの統合に適した構造になっていない場合がある
チームが現在のテストプラクティスを変えることに抵抗するかもしれない
カバーすべき未テストの機能のバックログがあるかもしれない

新機能や重要な領域にCucumberを適用することから小さく始め、チームがその利点を見るにつれて徐々に使用を拡大しましょう。

これらの課題にもかかわらず、多くのチームがCucumberテストの利点がデメリットをはるかに上回ることに気づいています。コミュニケーションの改善、より明確な仕様、ライブドキュメントは、より高品質なソフトウェアとスムーズな開発プロセスにつながることが多いです。

Cucumberの採用は旅です。小さく始め、成功を祝い、進みながらアプローチを調整しましょう。忍耐と粘り強さで、よりコラボレーティブで理解しやすく効果的なテストの恩恵をすぐに受けられるようになります。

関連記事: SpecFlow vs Cucumber: アジャイルに最適なBDDツールは？

まとめ

Cucumber Testingは技術チームと非技術チームのメンバーのギャップを埋め、ライブドキュメントとしても機能する明確で読みやすいテスト仕様を提供する強力なツールです。学習曲線や時間投資などの課題はありますが、その恩恵はデメリットを上回ることが多いです。コミュニケーションの改善、テストの明確さの向上、最新のドキュメントの提供により、Cucumberは開発プロセスを大幅に合理化できます。小さなプロジェクトから複雑なシステムまで、Cucumberの汎用性はテストツールキットへの価値ある追加となります。ぜひ試してみましょう。チームにとってよりスムーズでコラボレーティブなソフトウェア開発の秘訣になるかもしれません。

よくある質問

Qodex.aiを選ぶ理由は何ですか？

Qodex.aiはAI搭載のツールと自動化を活用して、APIテストプロセスを簡素化・加速します。その特徴は以下のとおりです。

AI搭載の自動化

一行のコードも書かずに100%のAPIテスト自動化を実現します。Qodex.aiの最先端AIは手動作業を削減し、卓越した効率性と精度をお届けします。

ユーザーフレンドリーなプラットフォーム

PostmanやSwagger、アプリケーションログからAPIコレクションを簡単にインポートし、数分でテストを開始できます。急峻な学習曲線や技術的な専門知識は不要です。

カスタマイズ可能なテストシナリオ

AIによるテスト生成と手動でのテストケース作成のどちらでも、Qodex.aiはお客様のニーズに対応します。プロジェクトの要件に合わせた堅牢なシナリオを構築できます。

リアルタイムの監視とレポート

APIの健全性、テスト成功率、パフォーマンス指標に関するインサイトを即座に取得できます。統合ダッシュボードにより常に状況を把握し、問題を早期に特定・対処できます。

スケーラブルなコラボレーションツール

あらゆる規模のチーム向けに設計されたQodex.aiは、シームレスなコラボレーションを促進するテストプラン、スイート、ドキュメントを提供します。スタートアップ、エンタープライズ、マイクロサービスアーキテクチャに最適です。

コストと時間の効率化

手動テストのオーバーヘッドをなくすことで時間とリソースを節約します。Qodex.aiの自動化により、運用コストを削減しながらイノベーションに集中できます。

CI/CD互換性

Qodex.aiをCI/CDパイプラインに簡単に統合して、開発ライフサイクル全体で一貫した自動テストを実現できます。

Pythonのregexを使用してメールアドレスを検証するにはどうすればよいですか？

次のregexパターンを使用してメールアドレスを検証できます: ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$

Go Regex Testerとは何ですか？

Go Regex TesterはGo開発環境で正規表現をテスト・デバッグするための開発者向け専門ツールです。regexパターンのリアルタイム評価を提供し、効率的なパターン開発とトラブルシューティングに役立ちます。