テストコードの期待値はDRYを捨ててベタ書きする ～テストコードの重要な役割とは？～ - Qiita
はじめに みなさん、DRY原則はご存知でしょうか？ DRY = Don't repeat yourselfの略で「繰り返しを避けること」という意味ですよね。 良いコードを書くための重要かつ基本的な原則なので、みなさんよくご存知だと思います。 ですが、DRY原則はテストコードを書く場合は必ずしも最善にはならない場合があります。 他の人が書いたテストコードを見ていると、テストコードにDRY原則を適用したために、かえって悪いコードになっているケースをときどき見かけます。 この記事ではなぜテストコードをDRYにすると良くないのか、ということを説明します。 追記：タイトルを変更しました @t_wada さんのコメントを受けて、タイトルを見直しました。 「テストコードはDRYを捨ててベタ書きする」 => 「テストコードの期待値はDRYを捨ててベタ書きする」 【注意】この記事は画一的なテストコードの書き
Git利用時のフローはどれを使うか - Qiita
Git, GitHub, GitLabそれぞれの特徴 *注意事項：当初は、GitHub Flowを入れる想定で調べていましたので少しGitHub Flowとの比較の観点が強いです Git Flow 使用するブランチ master マイルストーン用のブランチ develop 開発用のブランチ feature 機能追加用 (hot)fix 不具合修正用 release リリース準備用 Git Flowの良さ fix(不具合)の数が一目瞭然 masterを見ればマイルストーンの遷移が一目瞭然 参考：git-flowとプロジェクトの運営 Git Flowのまずさ ほとんどのツールがデフォルトでmasterブランチを表示するが、わざわざdevelopブランチに切り替えないといけない hotfixブランチをdevelop, master共に反映しなければならない点が面倒 参考：【翻訳】GitLab f
Qiitaっぽいメモアプリをつくってる話 - 鳥小屋.txt
Potmum（ぽっとまむ） ソースコード： https://github.com/rutan/potmum デモページ： https://potmum-demo.herokuapp.com 身も蓋もない言い方をすればQiitaクローンです。と言っても、用途がQiitaとは違うのでフォロー機能が無かったり、ちょこちょこ機能が違います。 Potmumは菊の鉢植えです。きーく。 なぜ作ったのか？ 僕のSimplenoteが整理不能になったためです(´・ω・｀) livedoor Wiki→Evernote→Simplenoteとメモ置き場を住み替えていき、SimplenoteでMarkdown最高！！という結論に至ったのですが、いまいちタグ機能とかが使いづらかったので、タグが付いてない記事だらけになってしまったのでアクセス性がとても悪くなってしまいました…… 本当はQiitaTeamを使おうと思
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gitでマージ済みブランチを一括削除 - Qiita
