休日個人開発で学ぶテストコード！ 画像に“集中線”を合成するツールを作ってみよう - エンジニアHub｜Webエンジニアのキャリアを考える！
休日個人開発で学ぶテストコード！ 画像に“集中線”を合成するツールを作ってみよう プライベートでも何か作りたい！ そんなときの「今日からはじめる休日個人開発」シリーズ、第二弾はテストコードを書きながら簡単なMVCモデルの画像加工ツールを作ってみましょう。好きな写真に集中線を合成できます。 皆さん、プライベートで何か開発していますか？ 「何か作りたい」という気持ちはあるものの、いまひとつ何から始めたらいいのか分からず、動けないままの人も多いと思います。 そんな皆さんのために、「仕事以外にも休日に個人で気軽に何かを作ってみよう！」という企画の第二弾です。今回は、第一弾で用意した開発環境を使って、画像を加工するツールを実際に作っていきます。 せっかくですので、ただ作るだけではなく、テストコードも一緒に書いてみましょう。最近は、CI（継続的インテグレーション）やCD（継続的デリバリー）も一般的にな
レガシーコードの触り方 / Working Effectively with Legacy Code
オープンセミナー2017@岡山
デバッグ用にechoやprint_rを書く代わりにテストを書こう - Qiita
こんにちはみなさん 偉い人は言いました Whenever you are tempted to type something into a print statement or a debugger expression, write it as a test instead. 何かを print 文やデバッガの式に書きたくなったときは、 代わりにその内容をテストに書くようにするんだ。 -- Martin Fowler さて、これはPHPUnitのマニュアルサイトに、突如として書かれている文言です。 Martinさんといえば、アジャイルソフトウェア宣言をした偉人の一人です。 テストコードを書くとなると、なかなか敷居高いもので、特に既存システムがゴミだったりすると、導入など夢のまた夢ということもママあります。 一方で、echoとかvar_dumpとか使って、こっそり内部動作を覗いて、コードが
テストコードのないプロジェクトにテストコードを導入した話 - Qiita
背景 現在私が参画しているプロジェクトは、プロダクトコードに対するテストコードがありません。 ※正確に言うと、ものによってはあるけど全体に対する割合で言うと0.5～1割程度だったので、ほぼないと言える状態。 そのため、 デッドコードが存在するプロダクトコード(品質) 責務が曖昧で長すぎるメソッド(品質) そもそもどこからも使われていないクラスの存在(品質) デグレ(品質) 保守対応(リファクタリング、業務影響のない軽微なバグの改修)の際のリグレッションテスト工数増大(コスト) テストコードを書かない文化 といったように様々な角度からの負がありました(挙げようと思えばもっとあるかも)。 目的 上記背景にある負を少しでも解消することを目的にテストコード導入推進を行います。 前提 言語：java テスティングFW：JUnit(色々検討した結果これに決定) CI：リリースブランチへマージのタイミン
テストコードにまつわる5つのエトセトラ - give IT a try
はじめに ひとつ前のエントリでRSpecの話を書いたので、それにちなんで最近僕の身の回りで起きたテストコードに関する雑多なエピソードをいくつか書いてみます。 その１：テストコードを書いてない処理で見事にバグを出してしまった・・・！！ 僕はソニックガーデンの中では「テスト番長」の異名を持っていて、基本的にテストコードはしっかり書くタイプです。 ですが、どうしてもリリースを優先しなければいけないときは、やむを得ずテストコードを後回しにして先にリリースすることもあります。 先日リリースした「テストを後回しにしたコード」は、リリース直後は問題なく動いていました。 その数週間後、別の仕様変更が入り、変更したコードをリリースしました。 「テストは全部パスしているので大丈夫なはず～！」と思ったら、リリースの翌日に変なシステムエラーが発生。 エラーが起きている場所を見て、ガーン。 例の「テストを後回しにし
レガシーコードのテストを書いていくテクニック - Qiita
Symfony meetup #13 LT 発表 レガシーコードのテストを書いていくテクニック はじめに レガシーコードにテストを書くのはきつい。 頑張ってE2E書くか、fixtureを用意してDBを使ったテストをする （むしろそれしか方法がないぐらい） でもクリティカルなところはユニットテストで確かめながら開発したい じゃあ、ユニットテストどうするか？ レガシーコード改善ガイドを参考にする スプラウトメソッド 新しく機能を追加する場合には新しくメソッドを作る。そこにテストを書く ラップメソッド 新しく機能を追加する場合に既存のメソッドに手を入れず、ラップしたメソッドに機能を追加する 新しく書くコードなら テストできる ＼(^o^)／ スプラウトメソッドのサンプル 機能追加前 （レガシーコードはだいたいstatic…） // legacyなstaticメソッドはテストが困難 public
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
