私は、Cursesベースのプログラミングの少しを探求するペットプロジェクトに取り組んでいます。これのための単体テストを書くための最良の方法は何ですか？私はRailsアプリケーションがサポートしている一般的なナビゲーション型テスト（統合テスト）について考えています。 （たとえば、自分のアプリが開かれ、1つのアイテムを下に移動し、優先度を上げ、完全にマークしてから、正常に終了することを確認したい）私はCursesアプリケーションの単体テストをどのようにテストできますか？
もう少し文脈があると、my appはncursesw gemを使用します。どんなテスト方法も素晴らしいでしょう。 （Ruby、Cなど）
非cursesアプリケーションをテストするのと同じ方法です。ユーザーインターフェイスからロジックを分割し、ロジックのみをテストします。
メニューをテストしないで、メニュー項目が呼び出す機能をテストします。
どのような側面をテストしたいかによって異なります。 ncursesのテストでは、トレース機能（コンパイル時オプション）があり、詳細な情報が得られます。
これは、ほとんどの人にとって低レベルであり、レベルを上げるには、一般に、（ライブラリを使用して）スクリーンダンプ機能を書くことが推奨されています。ライブラリは
のncursesライブラリは、スクリーンダンプ/リストアする機能を提供していますが、ncursesの古いバージョンの情報は、バイナリ形式（1が望むかもしれないよりいくつかの点ではあまり柔軟）に保存されます。これはファイルをテキスト形式にダンプするためにbeginning of 2015で改訂されました。副作用として、ダンプをdiffすることははるかに簡単です。
screendumpsを行わず、あなたが画面をキャプチャし、外部フレームワークのいずれかに依存しなければなりません（とそれが複雑になる傾向がある：にコメントを約"easy to use"ではなく、現実的なより楽観的である）、または画面を検査するために誰かに依存していると彼らが正しく見えることを確認してください。ディレクトリエディタでscreendumpアプローチを選択し、log commandsとし、screendumpsを実行するコマンドを追加しました。コマンドを再生して（そして連続した実行を比較する）、私は違いをテストすることができます。
さらに読書：
ありがとう - これは良い情報です。私は、アプリケーションとncursesの統合をテストする方法をもっと知りたいと思っています。私はこれをよりよく反映するように質問を編集しました。 –
は理にかなって - 私は、メニューをテストするために何のストレートフォワードな方法はありませんと仮定しますか？具体的なキー押下などが正しいメニューと機能にマップされていることを確認することに興味があります。あるいは、これは一般的に手動のQAテストに有利ですか？ –
ある時点で線を描き、信頼できるコードを書くために他の開発者を信頼する必要があります。あなたはメニューを模倣することができますが、それは本当の苦痛とほとんど利益をもたらさない - メニューのプレスはほとんど変更されません。テストを書くとき（私はおもちゃアプリよりも大きい）、私はユーザーインターフェイスを無視し、ユーザーインターフェイスが何を呼び出すかをテストします。 –
ご清聴ありがとう！テストのベストプラクティスは、常に私にとって灰色の領域でした。 –