私がTDDを実践しない理由（翻訳）｜TechRacho by BPS株式会社
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: 37signals Dev — Pending tests 原文公開日: 2023/03/01 原著者: Jorge Manrubia -- 37signalsのエンジニアです 日本語タイトルは内容に即したものにしました。 私は「テストファースト」で作業することも、テストでコードの設計を支援することも、めったにありません。 最近の私は、37signalsである新しいことに取り組み始めました。何も決まっていない白紙の状態なので作業はすいすい進み、来る日も来る日もこってりしたプルリクを作成しています。会議に先立って早めに投げておきたいと思っていたプルリクには、もれなく以下が含まれていました。 ご覧のように、私はほとんどの場合テストを最後に書いていることが見て取れます。例外があるとすれば、テストを書くことで最短で結果をフィードバックで
Rails: Content-Security-Policyの検証方法と、SeleniumとCupriteの比較（翻訳）｜TechRacho by BPS株式会社
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: Verifying Content-Security Policy with Selenium and Cuprite | Arkency Blog 原文公開日: 2022/11/17 原著者: Paweł Pacana サイト: Arkency Blog -- Rails Event StoreをサポートしているRailsアプリケーション開発会社です 日本語タイトルは内容に即したものにしました。 参考: コンテンツセキュリティポリシー (CSP) - HTTP | MDN その昔、RailsEventStoreの熱心な愛好家がissueを報告してくれたことがありました（#1062）。それによって、RES::Browserコンポーネントが、彼らのRailsアプリで使われている十分筋の通ったContent-Security-Pol
Rails 7 API: ActiveRecord::FixtureSet（翻訳）｜TechRacho by BPS株式会社
概要 MITライセンスに基づいて翻訳・公開いたします。 英語API: ActiveRecord::FixtureSet バージョン: Rails 7.0.0 サイト: api.rubyonrails.org ライセンス: MIT-LICENSE 2019/07/11: 初版公開 2021/12/17: 5.2.3->7.0.0に更新 以下も参考にどうぞ。 週刊Railsウォッチ（20190708-1/2前編）ActiveRecord::FixtureSetがめちゃ強くなってた、MacだとRubyが遅い理由、Puma 4登場ほか 銀座Rails#13の発表スライド↓ Rails API: ActiveRecord::FixtureSet（翻訳） fixtureとは、テストの対象としたいデータ（つまりサンプルデータ）を組み立てる手法のひとつです。 fixtureはYAMLファイルに保存されます
C++: コンパイル時テストのススメ｜TechRacho by BPS株式会社
皆さん、C++のテストフレームワークは何を使っていますか？ 最近はBoost.Testやgoogletestあたりが一般的ですね。私は個人的に IUTest というものを使ったりもします。 しかし、C++はコンパイル時計算を行う言語です（個人の感想です）。 だったらテストだってコンパイル時にやりたいと思いませんか？ 思いますよね。やりましょう。 コンパイル時テストのやり方 C++にはstatic_assertという機能があります。コンパイル時に式を評価して、falseになった場合コンパイルエラーにしてエラーメッセージを出してくれる機能です。 高機能なテストフレームワークを使うのも便利ですが、コンパイル時に解決できるテストはこれを使って書くことができます。 static_assertの文法は単純です。任意のboolに変換可能な定数式をexpとすると、 static_assert(exp, "
Railsのテスティングピラミッド（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: The Rails Testing Pyramid 原文公開日: 2013/10/09 著者: codeclimate テストの速度が期待より遅くなっていませんか？それとも、テストが不安定でリファクタリングやアプリ機能の根本的な変更もままならない状況になっていませんか？長年運用されている大規模なRailsアプリではこうした不満をよく目にしますが、テスティングのためのよい手法が浸透していれば、こうした問題が長期に渡って発生することはないはずです。 「テスティングピラミッド」のコンセプトは、テストのバランスの維持やテストスイートの高速化、アプリの機能変更コストの削減に有用であり、テストスイートにおけるさまざまな種類のテストを組み立てるときの中心に位置づけられます。 Railsで最もよく知られている2種類のテストについては皆さんも既に実
技術的負債を調査する10のポイント（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Our 10-point technical debt assessment 原文公開日: 2017/10/12 著者: Bryan Helmkamp サイト: https://codeclimate.com/ 6年前に画期的にシンプルなコード品質測定基準を導入して以来、コードの品質を高め、チームの生産性を向上させるのは「明確かつ実行可能な測定基準」であることがわかってきました。次の段階として、プロジェクトを明確に理解する新しい方法を提供するために、コード品質の測定とトラッキング方法に最近改良を加えました。 私たちの新しい評価システムは、「保守のしやすさ」（「技術的負債」と反対の概念）と「テストカバレッジ」という2つの柱の上に構築されています。テストカバレッジの算出方法はシンプルです。テストでカバーされたコード行数を、カバー可能な
ソフトウェアテストでstubを使うコストを考える（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Cost of stubs in tests 原文公開日: 2017/12/09 著者: Dmitriy Nesteryuk 本記事では、テストで何かと見かけるstubについて考察します。stubやmockは便利だと思う人もいれば、そう思わない人もいたりします（stubとmockは別物ですが、両者の違いは本記事の範疇ではないため、まとめてstubと呼ぶことにします: どうかご了承ください）。この話題は私が働いているチームではすっかり落ち着いていたのですが、最近になってまた話題にのぼったので、この際私の考えをざっくりここにまとめることにしました。誤りや見落としがありましたらぜひお知らせください。 かつての私は、依存をstubするのが大好きな開発者でした。テストが簡単に書けますし、読みやすく、しかもシンプルです。 class Cust
Rails: ActiveRecord関連付けのpreload/eager-loadをテストする2つの方法（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Two ways for testing preloading/eager-loading of ActiveRecord associations in Rails 原文公開日: 著者: Robert Pankowecki サイト: Arkency -- RailsやReact.jsの開発・教育・書籍を手がけています。 パフォーマンスに気を配っている開発者なら、#includes、#preload、#eager_loadなどの読み込みメソッドでN+1クエリを回避する方法をご存知でしょう。しかし自分の仕事が正しかったかどうか、期待する関連付けが本当にpreloadされているかどうかをチェックする方法はあるのでしょうか。そもそもどうやってテストすればよいのでしょうか。方法は2つあります。 Railsアプリに次の2つのクラスがあるとし
RSpecで役に立ちそうないくつかのヒント（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: A Few RSpec Helpful Hints 原文公開日: 2017/07/12 著者: Jake Yesbeck 2017/07/24: 初版公開 2023/05/11: 更新 Rubyにおける二大テスティングフレームワークといえば、RSpecとMiniTestです。RSpecは（訳注: 英語的に）非常に表現力の豊かなテスティングフレームワークであり、テストを読みやすくする素晴らしい機能やヘルパーが多数用意されています。ここでは、RSpecのテストを書きやすく、読みやすく、メンテしやすくするのに役立つ、あまり知られていないテクニックをご紹介いたします。 以下は、BooksとAuthorsがあるシステムのコードです。読みやすいテストコードを書いてみましょう。 class Book attr_reader :title, :g
Ruby: テストを不安定にする5つの残念な書き方（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 元記事: Five ways to write a flaky test 原文公開日: 2016/10/21 著者: Kir Shatrov（@kirshatrov） 2017/05/08: 初版公開 2023/03/01: 更新 不安定なテストは、日々の苦労を台無しにしてくれる技術上の負債の一部となります。テストが不安定だとCIが赤信号になってしまい、それだけのために新しいコードのリリースを中断してビルドをやりなおすはめになります。実際のコードはどこもおかしくないのに、どこかがおかしいのではないかという疑念が湧くと、ストレスの元になります。 数百人の開発者と5万件のテスト項目があるような大規模案件1では、不安定なテストが混入する可能性がさらに高まります。 本記事で扱うデモの中には、テストの実行順序に関連するものもありますが、そうでないものも
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
