雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try
（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
リーダブルテストコード / #vstat
「リーダブルなテストコードについて考えよう ～VeriServe Test Automation Talk No.3～」で使用したスライドです。 https://veriserve-event.connpass.com/event/243280/ 登壇動画はこちらで公開されています。 https://vimeo.com/742517199/e001ac43ac ＜参考リンク＞ Twitter https://twitter.com/jnchito Blog https://blog.jnito.com/ Qiita https://qiita.com/jnchito プロを目指す人のためのRuby入門［改訂2版］ https://gihyo.jp/book/2021/978-4-297-12437-3 Everyday Rails - RSpecによるRailsテスト入門 https://
希薄化したTDD、プロダクトの成長のために必要なものは？〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （６）
テスト書くのが当たり前、だけど・・・和田：次に意味の希薄化ですね。『Test-Driven Development by Example』の出版から15年経ち、テストコードを書く人はすごく増えました。15年前は啓蒙期で、テストコードを書きましょう、テストコードの書き方はこういう感じですというのを頑張って啓蒙する必要があった。 でも、例えば今の若手プログラマーは普通にテストコードを書く。なぜなら既存システムにはテストコードが書かれているから、開発の継続、不具合の修正とか機能追加を行う際にテストコードを書くのが普通だし、テストコードが無いとレビューは通らないしみたいな話になって、テストコードがあるという生活は普通のものになっている。そうすると、なぜテストコード書くのかとか、本来こういうテストコードを書きたかったんだけどとか、こういうテストを書くべきなんだけどみたいな議論はだいぶ土俵から外れてし
「一つのことをうまくやる」に忠実たれ。Serverspec開発者mizzyが語る成功するOSSの設計｜ハイクラス転職・求人情報サイト AMBI（アンビ）
「一つのことをうまくやる」に忠実たれ。Serverspec開発者mizzyが語る成功するOSSの設計 過去、手動と目視による作業が常だったサーバーのテストを圧倒的に簡易化するServerspec。国内外で高い評価を得るこのOSSの開発舞台裏を、作者の宮下剛輔（mizzy）さんが語ります。 2014年1月、世界中の優れたオープンソースプロジェクトを表彰するアワード「Open Source Rookies of the Year 2013」で、日本発のあるツールが選定されました。Dockerなど名だたるソフトウェアと並んで入賞したそのツールの名は「Serverspec」。 Serverspecとは、一言で表現すれば、サーバーのテストを自動化してくれるオープンソースソフトウェア（以下、OSS）のツールです。過去、手動と目視による作業が常だったサーバーのテストを圧倒的に簡易化するServerspe
Bashアプリケーションをテストする | POSTD
以前、bashスクリプトをテストする仕事に取り組んだことがあります。最初、Pythonユニットテストを使うことにしましたが、プロジェクトに外部技術を持ち込むのは気が進みませんでした。そこで、仕方なく、悪名高い bash で書かれたテスト用フレームワークを使いました。 既存ソリューションの概要 手に入るソリューションを探してGoogle検索しましたが、選択肢はほんの少ししかありませんでした。そのうちいくつかについて、詳しく見ていきましょう。 重要になるのは、どんな基準でしょうか？ 依存関係： bass のテスト用フレームワークを選ぶときに、 python 、 lua などのシステムパッケージも一緒に引きずり込むのは嫌ですね。 インストールの難しさ：継続的な開発の実装とTravis CIでの継続的な統合も仕事の1つだったので、私にとってインストールにかかる時間と手間数が妥当だということは、重要
はてなブログのデプロイを約6倍高速化したはなし - Sexually Knowing
今年、稼働中のサービスであるはてなブログのデプロイ方法を新しい方式へ無事故で移行し、従来と比べて約6倍速くデプロイできるようになりました。 この記事では、安全にデプロイ方式を変えたプロセスを順を追って紹介します。 はてなブログと継続的デリバリー デプロイが遅い 複雑なデプロイ設定 デプロイのテストを書く ボトルネックの発見、そして pull 型から push 型のデプロイへ 新デプロイへの移行 結果 まとめ はてなブログと継続的デリバリー はてなブログは1日あたり平均して1.02回デプロイを行っています。これは土日を除いた週5日の営業日に対する平均です。ざっくりとした算出で、祝日は考慮していません。5月と9月の祝日を含めるともう少し多くなるかもしれません。 また、原則として休日の前日にはデプロイしないことになっています。もしもデプロイした変更にバグがあった場合、休日が明けてから対応するか、
Quick/Documentation/ja at ja-docs · Quick/Quick · GitHub
README.md テストの書き方、Quickの使い方 Quickで書かれたテストで、SwiftとObjective-Cで書かれたプログラムがどう動作しているか、 楽に確認できます。 ところが、有用なテストはQuickを使わなくても書けます。 役に立つテストが書けるようになるには、 Quickのようなフレームワークの使い方を覚える必要はありません。 このディレクトリにあるファイルは、QuickかXCTestかを問わず、 「役に立つ」テストとは何か、そしてどうやってそういったテストが書けるか、 それを拙文ながら説明しようとしています。 目次： （テストについて事前知識がまったくない方は、順に読んでいくことをオススメします。） Xcodeでテストを用意しましょう : アプリのコードがテスト・ファイルから参照できない場合や、 その他スムーズにテストが動けない場合はこのファイルを読み返すといいかも
Test framework for Vim scripts
Vim script用のテストフレームワークはVCS系のプラグイン以上に乱立している。 各フレームワークの違いが分からなくなりやすいので、ここにまとめる。 まだ内容は工事中。 基本的に、現在の Vim からの実行にのみ対応だと実装が楽で確認も容易。 ただし実行結果がテスト環境の .vimrc, plugin 環境に依存してしまう。 テスト実行後の副作用の問題もある。 コマンドラインからの実行だと、副作用はないがテストの実行が面倒である(特に Windows 環境)。 プラグインが別のプラグインに依存している場合、runtimepath の指定が大変。 テスト用の関数を登録するものは、修正後の再ロードが難しい。 フレームワークには関数系とコマンド系がある。関数系のほうが記述の自由度が高く分 かりやすいが、テストの記述は長くなりがちである。 テストの構文は大きく分けて TAP 系と Spec
Expecta - Qiita
マッチャーフレームワーク for Objective-C/Cocoa ExpectaはGithubのメンバーが作ったマッチャーです。BDDフレームワークであるSpecta（これもGithub製）と組み合わせて使用すると、手軽にテストコードが書けます。特に非同期テストの書きやすさは秀逸です。是非皆さんも一度使ってみることをお勧めします。 このドキュメントは私がspecta/expectaから、自分が必要とする部分のみを抜粋して翻訳したものです。 翻訳に自信がない部分はそのままにしています。 セットアップ CocoaPodsを使用します。 target :MyApp do # your app dependencies end target :MyAppTests do pod 'Expecta', '~> 0.2.3' # expecta matchers # pod 'Specta', '
使えるRSpec入門・その3「ゼロからわかるモック（mock）を使ったテストの書き方」 - Qiita
はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第3回です。 今回はRSpecのモックを使ったテストについて説明します。 これまでモックを全く使ったことがない人でもわかるように丁寧に説明していくつもりです。 また、これまでの回と同様、個人的に使用頻度が低いと思っている内容についてはバッサリ説明を省きます。 ただし、第1回や第2回に比べるとテストコードが少し複雑になって、仕組みや動きを想像するのがちょっと難しいかもしれません。 ぱっと頭に入ってこない場合はじっくり本文を読んだり、実際に自分で写経しながらコードを動かしたりするなどして、少し時間をかけながら理解するようにしてください。 今回は以下のような内容を説明します。 モックの基本的な使い方 モックを使った検証 モックでわざとエラーを発生させ
ChefSpec by sethvargo
ChefSpec Write RSpec examples and generate coverage reports for Chef recipes! View on GitHub Download .zip Download .tar.gz ChefSpec is a unit testing framework for testing Chef cookbooks. ChefSpec makes it easy to write examples and get fast feedback on cookbook changes without the need for virtual machines or cloud servers. ChefSpec runs your cookbook(s) locally with Chef Solo without actually c
Testing in Swift
About the content This content has been published here with the express permission of the author. Software tests are great for verifying software behavior and improving the quality of your code. In this talk, we learn from Jeff Hui about tooling, techniques, and writing tested code with the Quick testing framework. He also talked about generative testing, a prevalent functional programming approac
RSpec 3の重要な変更 - 有頂天Ruby
Myron Marston » Notable Changes in RSpec 3の雑な訳です。 誤訳・雑すぎる訳がありましたら、Twitterで@nilp_までご連絡頂けると助かります。 RSpec 3.0.0 RC1が2日前にリリースされました、そして最終的な3.0.0のリリースが目前に迫っています。 我々はβ版をここ6ヶ月にわたり使ってきました、我々はそれらを皆さんと共有できることにわくわくしています。 これが新しいとこだよ: すべてのgemたちにわたって Ruby 1.8.6と1.9.1のサポートがなくなりました これらのバージョンのRubyはかなり前に寿命を迎えました、RSpecはこれらをサポートしません。 Ruby 2.xのサポート向上 最近のRSpec 2.xのリリース(すなわち2.0がリリースされたあと出たやつ)はRuby 2を公式にサポートしています、しかしRSpec
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TDDはOCD(強迫性障害)の一種か？
16. The power-assert Leaves From Moratorium | CodeLunch.fm
クックパッドはなぜ開発しやすいのか // Speaker Deck
Bitbucket | Git solution for teams using Jira
GitHub - Quick/Quick: The Swift (and Objective-C) testing framework.
クックパッドアプリの開発を支援する Appiumの話し 2014/10/18 第2回 日本Seleniumユーザーコミュニティ勉強
GitHub - modocache/personal-fork-of-Quick: This is a personal fork. Follow the canonical repo at Quick/Quick!
