C# で SOLID の原則に違反する危険性
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 C# で SOLID の原則に違反する危険性 Brannon King ソフトウェアを作成するプロセスが理論の段階から実際のエンジニアリングの段階に進化するにつれ、いくつか原則が生まれています。原則を当てはめるのは、コードの価値を維持できるコンピューター コードの 1 つの機能です。パターンとは、善し悪しは別にして、共通するコード シナリオのことです。 たとえば、マルチスレッド環境で安全に機能するコンピューター コードに価値を見出すかもしれません。あるいは、コードを変更してもクラッシュしないコンピューター コードに価値を求めることもあります。実際、有用な要素を数多く含むコンピューター コードには高い価値があり
)
Walkthrough: Using TDD with ASP.NET MVC
The ASP.NET MVC 2 framework. To download the most up-to-date version of the framework, see the ASP.NET MVC download page. The Contact.mdf database file. This database file is part of the sample project that you can download for this project: Download Creating a New MVC Application with Unit Tests In this section, you create a new Visual Studio solution that includes both the application project an
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
三角形問題で必要なテストケース数 - A Lifelong Software Tester (生涯一テスター)
Myersは「ソフトウェア・テストの技法」で自己診断テストの採点用チェックリストを示しています。このリストには「xxxのテストケースをもっているか」という13の項目と、「期待出力結果を書いているか」という項目の合計14項目が書かれています。13項目の中には3つの整数値の入力順序を変える(permutation)ものが含まれているので別々に数えると、Myersのチェックリストに合格するには最低22個のテストケースが必要になります。 では、Myersの三角形問題の正解のテストケース数は22個なのでしょうか? ソフトウェアテスト・ヒストリー(ソフトウェアテストPRESS Vol.8)のコラム「三角形問題の正解」で、米国のテスト・コンサルタントRoss Collardの"Exercise: Analyzing the Triangle Problem"を紹介しました。Collardは三角形問題のテ
テストコードのレビューについて - Qiita
はじめに TDDについて書いたところ、思ったよりも反響があり、様々なところでコメント書いていただきました。 ありがとうございます。 はてなブックマーク等に書かれている通りで、僕自身がTDDについて未熟なのは承知しております。 それを承知の上で僕が行った施策とTDDをやめた理由を文献に残そうとしたものがこちらの記事になってます。 さて、今回は頂いたコメントに関して僕の中で腑に落ちない内容であるテストコードのレビューについて書いていこうと思います。 成果物の管理について TDDを実践している人の記事やコメントで幾つか見られるのがテストコードのレビューが不要という内容です。 僕はこの考えにはかなり否定的です。 テストコードに限らず、自分がマネジメントしているチームのメンバーが作成したものは全て成果物という扱いになるというのが僕の考えです。 その成果物に関してレビュー（チェック）を行わないというの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
