単体テストの新しい名前[終了]

私はユニットテストが好きではありませんでした。それは私がしなければならない仕事の量を増やすといつも思っていました。
結局のところ、これは実際に記述するコードの行数に関してのみ当てはまり、さらに、これは、テストおよびテスト駆動開発で1時間で記述できる有用なコードの行数の増加によって完全に相殺されます。

ユニットテストが便利なコードを記述できるようになった今、私はユニットテストが大好きです。（木のノック）

厳格なタイムラインの下にある場合、または他の人がそれを行わないためにそうしないために、人々がユニットテストを行うか、テスト駆動開発でプロジェクトを開始することに消極的であることがわかりました。ちょっとみたい、文化的な拒否すらしよう。

ユニットテストの最も強力な点の1つは、リファクタリングを実行できるという自信です。また、コードを他の誰かにリファクタリング/改善するために与えることができるという新しい発見の希望も得られます。ユニットテストが引き続き機能する場合は、恐らくほとんど変更せずに、変更された新しいバージョンのライブラリを使用できます。

新しい名前が必要だと思うのは、ユニットテストのこの最後の側面です。単体テストは、このコードが現在、そして将来的に何をすべきかについての契約のようなものです。
テストという言葉を聞くと、ケージ内のマウスを思い浮かべます。化合物の有効性を確認するために複数の実験が行われました。これは単体テストとは異なり、さまざまなコードを試して最も効果的なアプローチを確認するのではなく、期待する出力と入力を定義します。マウスの例では、ユニットテストは、マウスで行われた実験とは対照的に、宇宙がどのように機能するかの定義に似ています。

私はひび割れているのですか、それとも他の誰かがテストを拒否するのを見て、それを彼らがテストしたくないのと同じ理由であると考えていますか？
テストしない理由は何ですか？
ユニットテストではないので、彼らの動機は何だと思いますか？

そして、いくつかの異論を乗り越えるかもしれないユニットテストの新しい名前として、jContractはどうですか？（私が知っている少しJava中心:)、またはユニット契約？

私はひび割れているのですか、それとも他の誰かがテストを拒否するのを見て、それを彼らがテストしたくないのと同じ理由であると考えていますか？

単体テストでのテストという言葉は、これが統合テストまたはユーザーインターフェイステストであると人々に思わせるものです。javaをjavascriptに入れるようなものです。

何かが悪い名前を持ち、それが人々の考えに影響を与えるとき、それはフレーミングエラーと呼ばれます。フレーミングエラーは表面的なものになりがちです。人々は賢く、あらゆる種類の悪い名前や悪い比喩を見ることができます。

テストしない理由は何ですか？

モック/偽物/困難な依存関係

ユニットテストではないので、彼らの動機は何だと思いますか？

ユニットテストのコンセプトカウントは控えめで、悪いユニットテストの作成をやめて、良いユニットテストの作成を始める前に、かなりの量の作業を行う必要があります。単体テストとは何かを説明するのが上手になると、採用は増加します。私の経験では、ユニットテストは生産性とコード品質に魔法のような効果をもたらします。しかし、それはそのように始まっていませんでした。もともと統合テストを作成するための便利な方法として、単体テストフレームワークを使用していました。

名称変更の概念はすでに提供されています。これはBehavior-Driven Developmentと呼ばれます。それを思いついた人たちは、同じ議論の多くに加えて、まだ作成されていないものをテストするための不自然な適合に気づきました。代わりに、それらの概念は実行可能な仕様を記述することです（これはとにかくTDDが実際に行うことです）。

私は同じ反発に気づきました。また、ユニットテストの作成方法を知らない人もたくさんいることに気づきました。それらは科学的プロセスの規律に欠けており、すべてを結び付けてデバッガーを起動する方法として単体テストフレームワークを使用するだけです。要するに、彼らは彼らの時間の使用を本当に改善しているわけではありません。数十行（30行以上）の長さで、1つのassertステートメントではないユニットテストの数はわかりません。それを見ると、開発者と協力して、アサーションとは何か、実際にテストする単体テストを作成する方法を教えるときが来たことがわかります。

コントラクトは、ここではほとんどの場合「インターフェース」と呼ばれます。単体テストを使用しても、テスト自体を変更できるため、コントラクト自体は保証されません。したがって、ライブラリがテストされているからといって、ライブラリの新しいバージョンを使用できるかどうかは実際にはわかりません。ライブラリを使用するコードもテストする必要があります。これは他の単体テストと同じなので、なぜ新しい名前が必要になるのかわかりません。

あなたのように、ほとんどの人はテストをするのをためらうのは、それがより多くの仕事で無駄だと思っているからです。

TDDが嫌いな理由をお話しします。その理由は、TDDの値が表示されなかったり、変更のたびにすべてのコードを検証するために実行できるテストスイートの利点を認識できないからではありません。

それは私がそれを必要としないからです。私はかなり古い学校の開発者です。私が小さかったとき、コードを書くために編集して続行する豪華な統合デバッガーがいなかったので、コンパイルにはかなり時間がかかるため、物事を取得する必要がありました右から、最初から。そのようなトレーニングを考えると、大量の単体テストを作成することで、生産性が向上したり、コードにバグがなくなるとは思えません。

私は自分のコードをテストしますが、いつものように、これは個々の部分ではなく全体について行われています。だから私は「ユニットテスト」を持っているかもしれませんが、それらはかなり粗いです。

それが私の理由です。私にはそれをする必要性が見えません。私が作成したコードは十分に優れていますが、その場合、壊れていないものを修正するためにプロセスを変更する必要があるのはなぜですか？