Unit tests vs class tests There’s a popular way of thinking that unit tests are basically tests for classes. I’d like to challenge this understanding. When I work on a codebase that is heavily class-tested, I find it harder to do refactoring. If all I want is to move some methods from one class to another, while preserving how the whole thing works, then I need to change at least two tests, for bo
疑似個人情報とは、主にアプリケーションの開発/試験の際のテストデータとしての使用を目的とした架空の個人情報データです。 個人情報保護法の施行により、本物の個人情報を目的外であるテストデータとして使用することはできなくなっています。 また個人情報の漏洩が社会問題となっている今、「本物の個人情報」をテストデータのように別目的で使用することは、 情報漏洩の危険性が高まるだけでなく、企業としてのモラルも問われます。 このページは無料で、この擬似個人情報を生成することができる実験的サービスです。 生成したデータの商用利用も可能です。 下の「生成を開始する」ボタンを押して、条件を入力していくだけで簡単に個人情報データの生成を行うことができます。 作成したデータはMicrosoft Excel、CSVなどの形式でダウンロードすることができます。
This post is co-authored with Michael Bolton. We have spent hours arguing about nearly every sentence. We also thank Iain McCowatt for his rapid review and comments. Testing and tool use are two things that have characterized humanity from its beginnings. (Not the only two things, of course, but certainly two of the several characterizing things.) But while testing is cerebral and largely intangib
Post-postscript: Think of this blog post with its feet up, enjoying a relaxing retirement after a strenuous career. Please read the new version first. In the years since the original post, I’ve further refined my take on the subject of testing and checking, mostly in collaboration with my colleague James Bach. Our current thinking on the topic appears on his blog, and I provide some followup here.
こんにちは、やまもと@テスト番長です。 このエントリーは「GREE Advent Calendar 2014」13日目の記事です。 最近はグリーのQuality Assurance部のテストエンジニアリングチームを担当しています。 品質管理を行う部署のため、エンジニアブログに顔を出すのは初めてなのですが、 今回はグリーのQA体制のご紹介および、テストエンジニアリング面からの 取り組みをご紹介させて頂きたいと思います。 グリーのQA体制について QAチームは、2011年の夏にカスタマーサポートチームから派生する形で組織されました。 2012年に起きたカード複製の不具合や未成年課金の問題など、多くのトラブルを経験・奔走しつつも徐々に体制を整え、現在は社員20名・協力会社の方々も加えると50名ほどのグループとなっています。 ネイティブゲーム、ウェブゲーム、ガレージスタジオ&プラットフォーム、テス
年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
プロローグ 読者の方で、次のように思っていらっしゃる方は、どれくらいいるでしょうか。 「いちばん重要な財産はコードであり、万一コードを失ってしまったら、元と同じ品質のコードをもう一度書くのはとても大変だ」 筆者も長年このように思っていました。では、もし以下のように考えたらどうでしょう。 「いちばん重要な財産はテストであり、万一コードをすべて失ってしまったとしても、テストが無事なら元と同じ品質のコードをもう一度書くことができる」 今までとずいぶん違う考え方ですね。いろんな声が聞こえてきそうです。 「コメントはどうするんだ」 「テストが複雑すぎて保守できなくなったらどうするんだ」 ごもっともです。テスト駆動開発は万能ではありません。うまく適用できない場面もあり、このときは従来どおりのやり方が必要です。たとえば、デバイス制御(あるタイミングでI/Oポートを叩くとか)などは、保守可能なテストを書く
2013年12月1日、オラクル青山センターでシステムテスト自動化カンファレンス(STAC)が開催されました。私自身はテスト自動化研究会(STAR)のコミッターですが、今回縁あってカンファレンスのレポート役をさせていただくことになりました。 それではさっそく報告に入りましょう。 よりよいテスト自動化のためにちょっと考えてみませんか?―スコープ、ROI、プロセスを中心に― 近江 久美子(STAR) 今回のカンファレンスの位置づけと全体の方向づけを行うものです。このカンファレンスで扱われるテストは「ソフトウェアのユーザに価値がある単位で行われるテスト」、一般的にはシステムテスト、受け入れテストと呼ばれるテストレベルになります。 次にテスト自動化の目的を考えましょう。代表的なものとしては効率化したい、手動ではできないテストをしたい、などが挙げられますが、大事なことはただ自動化してもよい自動化に
Today's tester role is more versatile and calls on a wide range of skills. Now testers have tasks throughout the sprint, and they also program — yes! — as regular programmers. (I don't say as developers, as all participants in the team are part of the development: the business analyst (BA), the designer, the tester, the tech writer and the programmers.) Testers don't need to be specialists in any
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く