バリデーター、理解して許してください

JRコースを修了した後でも、時々ヘルプセクションに来て、何かを提案したり、助けたりします。ほとんどの場合、質問は「すべて正しく行いましたが、バリデーターが許可しません」またはそれに類似したフレーズで始まります。私がここに書くきっかけとなったのは、これらの見出しでした。これからは、それを真実として受け入れることを提案します。検証者は常に正しいです。時々バグが現れることもありますが、そのたびにその数はどんどん減っていきます。したがって、バリデーターから拒否を受けた場合は、どこかで間違いがあったと考えることをお勧めします。そして今、壁に頭をぶつけないようにするために、テストの習得を始める必要があります。このトピックに関する記事がいくつかあります ( JUnit パート I JUnit パート II )。さらに、テストする必要があるのは「都合の良いケース」ではありません。たとえば、タスクtask1916を考えてみましょう。ソリューションを作成した後、理想的なオプションを確認することがよくあります。理想的なオプションはパスします。つまり、タスクを送信できます。そして、拒否反応が届きます。では、何をする必要があるのでしょうか? そうだ、別のテスト例を書いてみましょう。そして、バリデーターがテストに合格するまで、次から次へと続きます。たとえば、空の 2 番目のファイルに対してコードはどのように応答するでしょうか? 空の最初のものはどうですか？最新の例は次のとおりですhttps://javarush.com/help/15861 ここで、開発者はコードを書くだけでなく、テスターに​​頼るのではなく自分でテストする必要があることを理解することが重要です。正直に言うと、開発がテストフェーズに移行するときはまだ少し怖いです。私のコードは正常に動作し、エラーはないはずだと信じています。動作しないコードを配布すると、いつも気分が悪いです。私が何かを書いたがそれをチェックしなかったことが判明しました。誰かの時間を無駄にした。もちろん、後で仕事をするときに要件のリストが手に入り、テスターからソフトウェアのテスト ケースのセットを入手してそれに適応させることができるようになり、作業は簡単になりますが、私はそれを当てにはしません。コードはあなたの責任であり、テストはすべてが正常に動作することを確認するのに役立ちます。テスターのスキルを向上させる絶好の機会が与えられました。ヘルプ セクションに入るときは、コードの形式で作成者への回答を書き込まないでください。彼にとってはうまくいかないテスト例を考えてみましょう。こうすることで、著者に代わって問題を解決することなく、あなた自身が向上し、著者を助けることができます。