「レガシーコード改善ガイド」のススメ 第2回：コードを理解するため、仕様化テストで文書化する
増え続けるレガシーコード この記事を読んでいる皆さんの多くは、これまでたくさんのシステム開発に関わってきたことでしょう。仕様変更と闘い、納期に追われ、やっとのことで稼働したシステムも数多いはずです。厳しい状況になればなるほど、実際にコードを動かすことが最優先になり、「コードを保護する」ための単体テストの整備は後回しになってしまいがちです。 ところが、システム開発はシステムが完成して無事に稼働した時点で終わりではありません。ユーザーが実際に使い始めると、保守開発としてさまざまな仕様変更や機能追加が発生するのが常です。それらに対応するためには、厳しいスケジュールの中で、やっつけ仕事で間に合わせたコードに対して改修や機能追加をする必要があります。では、このような仕事にどうやって取り組めば良いのでしょうか？ さて、前回の記事では、『レガシーコード改善ガイド』におけるレガシーコードの定義を紹介しまし
レガシーコードのテストを書いていくテクニック - Qiita
Symfony meetup #13 LT 発表 レガシーコードのテストを書いていくテクニック はじめに レガシーコードにテストを書くのはきつい。 頑張ってE2E書くか、fixtureを用意してDBを使ったテストをする （むしろそれしか方法がないぐらい） でもクリティカルなところはユニットテストで確かめながら開発したい じゃあ、ユニットテストどうするか？ レガシーコード改善ガイドを参考にする スプラウトメソッド 新しく機能を追加する場合には新しくメソッドを作る。そこにテストを書く ラップメソッド 新しく機能を追加する場合に既存のメソッドに手を入れず、ラップしたメソッドに機能を追加する 新しく書くコードなら テストできる ＼(^o^)／ スプラウトメソッドのサンプル 機能追加前 （レガシーコードはだいたいstatic…） // legacyなstaticメソッドはテストが困難 public
自動テストのfixtureを効率的に管理する方法
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 僕がやっている案件(PHP)はもともとテストコードのないレガシーなプロジェクトで、それを改善するためにずっと動作を確認するための結合レベルの自動テストを増やしてきました。 そんな中で、僕のところではどうやってテスト用のfixtureを管理しているか事例として紹介したいと思います。 最初にコアとなるfixtureを用意するみんながたくさんテストを作る前にコアとなるテスト用のfixtureは用意しておきます。 さもないと、みんなが好き勝手にfixtureを作ってしまい、あっという間に混乱に陥ります。 プログラム本体と同様に、DRYの原則で、同じようなテストデータを繰り返し作ってしまうよう
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
TDDはゆるく実践しても大丈夫 - 千里霧中
最近、TDDのテストコードは捨てても良いかみたいな議論を見ました。 これに対する自分個人の経験上の意見ですが、TDDは雑多にテストコードを使い捨てても効果を出せると思います。 もちろん、TDDで保守性が高く価値あるテストを書いて、捨てずにCIや中長期的なリファクタリングで再利用していくと、TDDの効果を増幅できます。ただ、それをするにはスキルや事前の工夫、労力が必要ですし、できる場面に限りがあります。 そういったことをやらず、もっとゆるい姿勢で取り組んでも、費用対効果をプラスにできる手法がTDDだと考えています。 今回は、そのTDDでゆるくしてもよいポイントを、実経験からまとめたいと思います。 TDDのテストは使い捨てでいい TDDのテストはプログラマのこまごまな課題に応じて累積的に作られるため、保守コストがかかるテスト・保守する価値の低いテストが生まれがちです。そのためテストの使い捨ての
Unit Testing and Coding: Best Practices for Unit Tests | Toptal®
Unit testing is an essential instrument in the toolbox of any serious software developer. However, it can sometimes be quite difficult to know how to write unit tests for a particular piece of code. Having difficulty testing their own or someone else’s code, developers often think that their struggles are caused by a lack of some fundamental testing knowledge or secret unit testing techniques. In
JSTQB認定テスト技術者資格試験を受けてみたよ。 - naichi's lab
2015/08/29(土)にJSTQBFL試験を受けてきました。 とりあえずメモメモ。 JSTQB試験って何？ JSTQB認定テスト技術者資格 よくわかんないけどソフトウェアテストに関する知識を認定する資格らしい。なんだか怪しいよね。 ２つのレベルがあってとりあえず簡単な方を受けてみた。 なんで受けたの？ 会社にMicrosoftの人が営業にきたときに話が出て知った。正直聞いたこともなかった。 でも前職は「テストって何？」状態だったし転職した先も「とりあえずテストしといて。やり方？任せるよ」みたいな感じでこりゃダメだと思ったので軽い気持ちで受けてみた。 どんなテスト？ ソフトウェアテスト関係の基本情報処理試験みたいな感じ。 JSTQB認定テスト技術者資格-JSTQB認定テスト技術者資格試験実施要領- 広く浅い知識が身につく。 年２回やってるみたいだね。 難しい？ たぶん基本情報処理よりは簡
Friendlyのカレンダー | Advent Calendar 2014 - Qiita
About reserved postingIf you register a secret article by the day before the same day, it will be automatically published around 7:00 on the same day. About posting periodOnly articles submitted after November 1 of the year can be registered. (Secret articles can be registered anytime articles are posted.)
結合テストと呼ぶのをやめた話 - asterisc
はじめに 最近、意図的に「単体テスト」「結合テスト」という呼び方を避け、Google Testing Blogで紹介されてるTest Sizesによる分類（small / medium / large）に従った呼び方でテストを呼んでいる。 この分類方が自分の身の回りに徐々に浸透してきて、実際のチーム内のテスト戦略も一歩進んだ議論ができるようになってきたので、改めてまとめる。 ちなみにこの記事の話は手動で行われるテストではなく、自動テストを対象としているが本質はあまり変わらないと思う。 続き書きました。 akito0107.hatenablog.com 「単体テスト」「結合テスト」という呼び方について ソフトウェア開発に従事していれば必ず聞く言葉だと思う。改めて他のサイトから引用する形で定義をまとめておく。 単体テストとは *1 単体テストとは、プログラムを検証する作業の中でも、プログラムを
変更に強いアーキテクチャについてIT業界19年目の僕が超ザックリ説明する - Qiita
この記事は、設計・アーキテクチャ Advent Calendar 2018 の第7日目の記事である。 はじめに この記事では、IT業界19年目の僕が実践している変更に強いアーキテクチャについて、出来るだけ難しい表現を避け、教科書的なありきたりな内容ではなく現場の肌感覚に近い切り口で「超ザックリ」な解説を試みてみようと思う。 普段自分がよく用いている実装パターンの紹介ともいうべきかも知れない。 この記事で説明すること いざ「変更に強いアーキテクチャとは」とズバリ訊かれても、一概に「これだ！」という答えはない。 プログラミング言語や、フレームワークによっても条件が異なるし、利用可能な技術や開発チームの特性、業務要件や運用要件の特性によっても様々であるし、インフラや開発プロセスまで含めて考えると考慮すべきことは無限にある。 ここでは主にソフトウェアの構造という観点から、"変更に強い" ということ
テスト駆動開発って何だろう | DevelopersIO
はじめに モバイルアプリサービス部の中安です。 このたび、テスト駆動開発(Test Driven Development = TDD)の社内読書会を数ヶ月に渡って参加させていただきました。 原題: Test-Driven Development By Example 著: ケント・ベック 訳: 和田卓人 こういうものに参加するのも初めてなので「なんとかついていく」という感じでしたが、 最終的には無知識だった初めの印象から変わった部分も多く、有意義だったなぁという感想に至りました。 すでに社内読書会については素晴らしいまとめがありますので、 詳しくご覧になりたい方は下記のリンクをご覧くださいませ。 『テスト駆動開発』読書勉強会 では、自分はここに何を書いていくかというと、 「テスト駆動開発って何だろう」から始まった自分が読書会を通じてわかったこと 弊社に直接お越しいただき話をしていただいた、
DbSetのAddをMockでTestする - おでんはじめました。
書きなれないブログでタイトルからつまづいてますが。。。 EF6をServiceとMockを使っていい感じでテスト＆モッキューできないかなと。 元ネタはなかじさんのブログ。 blog.nakajix.jp ここの記事にあるEFのTestをMoqを使ってやる記事があります。 msdn.microsoft.com この中の「Testing query scenarios」が、サンプルデータをServiceを通してGetAllBlogsで取得するとorder byされて返ってくるというTESTです。 [TestMethod] public void GetAllBlogs_orders_by_name() { var data = new List<Blog> { new Blog { Name = "BBB" }, new Blog { Name = "ZZZ" }, new Blog { Na
Testing with a mocking framework - EF6
When writing tests for your application it is often desirable to avoid hitting the database. Entity Framework allows you to achieve this by creating a context – with behavior defined by your tests – that makes use of in-memory data. Options for creating test doubles There are two different approaches that can be used to create an in-memory version of your context. Create your own test doubles – Th
技術/TDD/JavaにおけるUnitTest時のMockオブジェクトの導入手法 - Glamenv-Septzen.net
id: 448 所有者: msakamoto-sf 作成日: 2009-10-02 10:11:49 カテゴリ: Java TDD プログラミング JavaでJUnitを使った単体テストのコードを書く時、Mockオブジェクトを使いたい、という場合がある。 例えばテスト対象のインスタンスメソッドの中で、トランザクションやデータベースの接続クラスのインスタンスをnewしていたりする時、 単体テストコードを作る為にMockのトランザクション/DB接続クラスに差し替えたい、というケース。 次のIBM developerworks の記事では、テスト対象のメソッドのインターフェイスを変えずに内部だけをリファクタリングし、 Mockオブジェクトに差し替える手法が紹介されている。 "Unit testing with mock objects" http://www.ibm.com/developerw
古めの組織に導入する自動テスト・アンチパターン集 - Qiita
アジェンダ そもそも、なぜ自動テスト？ 自動テストと騒ぐと冷たい目で見られる事もあるという話 個人・組織としての失敗談と、その処方箋 書かないこと テストがないレガシーコードにテストを組み込む方法については、触れない そもそも、なぜ自動テスト？ 自動テストは、うまく導入すれば、プロダクト品質の担保とユーザへのデリバリー速度に大きく寄与することが分かっているため。 Web業界の先端が、自動テストの効能を体現してる たとえばこんなフロー テストコードを書く プロダクトコードを書く テストコード、プロダクトコードをコミットしてプルリクを出す プルリクをマージすると、CI環境がロジックのフルテスト、UIのフルテストを走らせる テストが全部通ったらそのまま自動的にデプロイする コンピュータに任せられることは全てコンピュータに テスト実施は単純作業なので、人間が実施しなくても良いようになっている 人間
プログラマーも手動テストしようぜ 〜 忍者式テストのすすめ 〜 - Qiita
はじめに プログラマの中には、TDDのような自動テストを整備すれば、手動テストは必要なくなると考えている方もいるようです。本記事では、主にプログラマー向けに、手動テストの大切さとはじめ方を書きます。 はじめ方に忍者式テストが出てきます。 プログラマーが得意なテスト、不得意なテスト プログラマーはCheckingが得意です。Testingは不得意です。 テストには Testing と Checking の二つの作業がある Michael Boltonという人のお言葉があります。 Testing vs. Checking « Developsense Blog Checking Is Confirmation Testing Is Exploration and Learning テストにという行為はCheckingとTestingの二つの行為の分けられます。 Checkingは既知の不具合が
テストがうまくいかないプロジェクトに捧ぐ、正しいテストの考え方 - Qiita
この記事の対象者 プロジェクトでテストを書いている。(書いたことある) テストが重要らしい事は知っているが、テストの恩恵をそこまで実感できていない。 結局手動テストに依存したバグフィックスをしている。 はじめに 私はテストの設計手法、実装に関する知識は多く持っていましたが、知らなかったことはテストの考え方でした。 テストが重要らしいことを知っている人は多いと思います。 しかし、実際に恩恵を実感できていない人もいると思います。 事実、 テストが重要だと発信している人 と、 テストが重要らしいことを知っている人がいます。 後者の人は、とりあえずテストを書く事ができます。しかし、テストに時間を割く割りに、最終的には手動テストでバグを発見することに依存している事も多いかなと感じます。 世間ではテスト書くのが当たり前、テストは重要！という風潮であるのに、何故テストが重要であると実感できないのでしょう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なぜテストを書くの？（または書かないの？） 〜テストコードの7つの役割〜 / #tamarubykaigi01
Moq & Fakes Framework を使った実践的ユニットテスト - BuildInsider
システムテスト自動化のツボ