コードを単純にテストするのに長い時間がかかる場合、どのように効果的にプログラムしますか？

私のワークフローは、常に1つの論理ステップを記述してからプログラムを実行し、出力を検査することです。このプロセスは、大学での割り当てに非常に役立ちました。ただし、さらに開発を進めるにつれて、コードを単純にコンパイルして実行するのに1〜2分かかることがよくあります。例には、プログラムをマイクロコントローラーにアップロードすること、外部サーバーとの対話が必要であること、認証、ソフトウェアアーキテクチャ、または複雑さのために自動化を実装できないことが含まれます。

これらのタイプのタスクは、私が通常プログラムする方法には非常に不適切であり、効果的にコーディングするのが困難です。私は通常、多くの構文エラーと論理エラーを作成しますが、そのほとんどはテストで簡単に検出できます。ただし、このような長い待機時間では、この方法は時間がかかりすぎます。

まず、あらゆる種類のインタラクティブなデバッグが優れています。あなたはそれをあなたのツールキットに望みます。そうでないなら、いつかあなたはそれを持っていることから本当に恩恵を受けるでしょうから。（詳細は、言語、プラットフォーム、およびIDEによって異なります。）

外部サーバーとの対話が必要であり、認証、ソフトウェアアーキテクチャ、または複雑さのために自動化を実装できない。

モックオブジェクトを使用するためのいくつかのフレームワークを調べます。これらにより、テスト対象のコンポーネントを他のコンポーネントの偽のエコシステムで囲むことができるため、テストがより具体的にターゲットにされ、ユニット全体としてすべてをテストすることを回避できます。

さらに、モックオブジェクト自体をアサーションでプログラミングできるため、テスト対象のコンポーネントが実際に特定の呼び出しを行ったことを確認できます。

テスト時間を短縮するために一生懸命働きます。私は組み込みコードを開発しているいくつかの会社で働いていましたが、テストは苦痛でした。その後、本当にいいグループに参加しました。デスクで「テストを行う」と入力するだけで、1分以内に結果を得ることができました。その1分で：

• 私のコードは、組み込みハードウェアの新しいカーネルイメージに組み込まれました。
• DHCPサーバーは、新しいカーネルを指すように更新されました。
• テストボードが再起動されました。
• テストボードは、NFSマウント経由でワークステーションからカーネルを取得しました。
• テストボードは新しいカーネルで再起動しました。
• 単体テストが実行されました。
• 単体テストの出力がワークステーションに返されました。

このすべてを機能させるには時間がかかりましたが、開発スタッフが増加するにつれて、これらすべての手順を自動化する努力は100倍になりました。

自動化されたテストは、レビューと理解に代わるものではありません。

テストを松葉杖として使用している可能性があります。これをしている場合は、学習が妨げられます。私はあなたがテストしないことを主張していません。代わりに、テストレビューを実行する前に、書いた内容をお勧めします。あなたが書いたものを理解し、それが理にかなっていることを確認し、構文が正しく見えることを確認してください。

あなたはすでに答えを与えました： I usually make a lot of syntax errors and logic errors

したがって、それを改善するために一生懸命働くことで、テストの時間を短縮できるはずです。構文エラーは、最初に減らす必要があります。あなたの研究で紙と鉛筆を使ったプログラミングテストを受けたことはありませんか？

PHPからJavaに切り替えたときにも同じことが起こりました。いくつかの変数を印刷してブラウザでF5キーを押すのではなく、デバッグする方法を学ぶ必要がありました...

できればバックグラウンドで自動的にテストを実行できる優れたユニットまたは機能テストプラットフォームが必要です。これには、上記のようにモックを使用する必要があり、使用している言語に応じて、ある種の依存性注入を使用します。

オブジェクトを可能な限り独立させてから、注入メソッドを使用して外部制約を追加することにより、コードのテストプラットフォームを作成するのは難しくありません。

本当の楽しみは、怒りの中で使用する以外の方法でコードをテストできないときです。これは取引システムで非常に頻繁に発生します。利用可能な取引所シミュレータは、しばしば貧弱で、存在しないか、取引所ソフトウェアのサプライヤが言うことを遵守していません。これは私が恐れている人生の豊かなタペストリーの一部です。私のアプローチは、少なくともトランザクションの私の側が適切に記述され、文書化されていることを確認することです。そのため、簡単に素早く変更できます。

ユニットテスト; モックアプリケーション/シミュレータ。

これには時間がかかりますが、サンプルデータを収集して適切なモックアップを作成する必要がある場合がありますが、最終的には成果があります。外部に対してテストしようとするときに遭遇する時間と手間をすべて省くことができます。システム。

正しく使用すると、これらのツールは、外部システムの近くに行く前に、コードが失敗した場合、それが原因である外部システム/環境の変化であり、自分のコードのバグではないことを99.9％確信しています。

私はかなり長い間、彼らがあなたが学校でやったように専門的に働いていましたが、多くの場合、それは非常に効果的でした。結局、私はその方法論を放棄し、代わりに単体テストとモックアップを使用せざるを得ない人々の下で働きました。

今、私はテストフェーズの実装（ユニットテスト、モックアップ、シミュレータ、サンプルデータなど）を最初に考えずにプロジェクトを開始しません。

私は通常、多くの構文エラーと論理エラーを作ります

リンターを使用すると、ここで少し役立ちます。

私は以前の雇用主と同じような状況にありました。私たちのコードベースは本当に巨大で、コードに変更を加えるために、コンパイルしてから置き換えます.class dev-serverのファイルを、restartスクリプトでdev-severを再起動します。そして、残念なことに、開発サーバーを再び起動するのに約30分かかります。

後で、dev-serverのリモートデバッグも可能であることがわかりました。

プロセスを最適化するために私がしたことは

• 最初のリモートデバッグの最初のラウンドでは、これにより正確なコードフローと変数の正確な値/状態を確認できました。

• どのように、どのような変更を加えるかを計画します。

• 変更を行ってから差分を比較する

• リンターを使用するかコンパイルすることにより、ミスをキャッシュします。

• .classファイルを置き換えて再起動することにより、ホットフィックスを提供します。

コードフローを再度確認し、値/状態を確認するために、大量のログステートメントを含めることもあります。これは私を大いに助けてくれました。

また、自動コンプリケーションの良いIDEを使用すると、タイプミスを大幅に減らすことができます。

お役に立てれば。