受け入れテストフレームワークは、バックエンド開発に適していますか？

Question

バックエンドとは、データを消費したり、ファイルを処理したり、マシンインタフェース（REST、SOAP、CORBAなど）を使用して通信するソフトウェアシステムを意味します。派手なWebやUIテストは必要ありません。私はキュウリとRobotframeworkを心に持っていますが、私は彼らが手近な課題にどれくらい適しているか分かりません。

Answer 1

私は、informala変換であるperlとplsqlで書かれたバッチアプリケーションをテストするためにCucumberを使用しており、現在はテレフォニーIVR /キューイングシステムのテストに使用しています。 Rubyは私がシステムを動かすのに必要な宝石を提供しました。そして、テスターが言語/構文を学ぶのはとても簡単でした。

Answer 2

この質問に対する簡単な答えはありません。

あなたのドメインが正しくなっているように聞こえる... UI/Webコンポーネントをテストしようとすると、受け入れテストフレームワークがその仕事の正しいツールにならないからです。

あなたはいくつかのオプション

• SpecFlow
• キュウリ
• を持つ落語
• FitNesseの
• mSpec
• いくつかの他。

私はStoryTeller & mSpecに部分的ですが、これらのツールのそれぞれには長所と短所があります。テストを維持/書き込みをしようとしているあなたは（しているとあなたのチーム）あなた自身に尋ねるべきである
質問

• ？
• 自己証明書受諾テストはあなたの組織にとって価値がありますか？
• 現在のビルドプロセスと最も簡単に統合できる技術はどれですか？

Answer 3

Robot Frameworkについては、私はIntellijでこの点について悪いサポートを受けています。私はIntelliBotプラグインを使用しています。多くの場合、誤った構文のような間違いを知り、テストランタイムの後半でキーワードなどを見つけることができません。 インポートされたライブラリを見つけたり、デバッグしたり、プロジェクト全体でrenameキーワードのような単純なリファクタを見つけたりすることに問題があります。