privateメソッドのテストって書かない方がいいんだっけ？PHPerKaigi 2024発表資料 https://fortee.jp/phperkaigi-2024/proposal/f23f927e-2ac8-498e-a047-6376831cbd07
Selenium (Ruby) やCapybaraの弱いところをPuppeteerで救いに行く - YusukeIwakiのブログ
「puppeteer-rubyは、Capybaraと共存して動作精度を向上できるのでは？！」っていうことに先週くらいにふと気づいたので、カッとなって実装してみた。 github.com CapybaraとPuppeteerの共存 そもそもなんで共存させる必要があるのか？ Seleniumだと「○○の要素が現れるまで待つ」「△△の要素が消えるまで待つ」みたいなところで、時々DOMの変化通知を拾いそこねて、失敗してしまうことがある。 PuppeteerはDOMの変化通知には強い。ただ、全部をPuppeteerで書き直す気力は無い...。 みたいな感じで、SeleniumやCapybaraの既存コードをなるべく書き換えないうえでPuppeteerのを動かしたい需要は、割とある気がした。 で、需要はありそうなのに、世の中にあるのは twalpole/apparition rubycdp/cupri
自動テストに限界を感じた私がなぜ形式手法に魅了されたのか - 若くない何かの悩み
長らく自動テストとテスト容易設計を生業としてきましたが、最近は色々な限界を感じて形式手法に取り組んでいます。 この記事では、既存の自動テストのどこに限界を感じてなぜ形式手法が必要なのかの私見を説明します。なお、私もまだ完全理解には程遠いため間違いがあるかもしれません。ご指摘やご意見はぜひ Kuniwak までいただけると嬉しいです。 著者について プログラマです。開発プロセスをよくするための自発的な自動テストを支援する仕事をしています（経歴）。ここ一年は R&D 的な位置付けで形式手法もやっています。 自動テストの限界 自動テストとは 私がここ数年悩んでいたことは、iOS や Web アプリなどのモデル層のバグを従来の自動テストで見つけられないことでした。ただ、いきなりこの話で始めると理解しづらいと思うので簡単な例から出発します。 この記事でいう自動テストとは以下のようにテスト対象を実際に
JUnit 5 のパラメーター化テストは超便利 - Qiita
JUnit 5 といえば @Nested テストが一押しかなと思っていた時期もありましたが、 @ParameterizedTest を使い始めたら「JUnit 4 のあれは何だったんだ」と思えるくらい手になじんでとてもいい感じです。これだけでも移行をオススメできます。 確認環境 JUnit 5.3 AdoptOpenJDK 11.0.3+7 macOS 10.14.3 ValueSource パラメーターは、@ValueSource アノテーションを使って指定します。パラメーターの型に応じて、ints や strings、 doubles プロパティなどがあります。 @ParameterizedTest @ValueSource(ints = {1, 2, 100}) void positiveNumber(int n) { assertTrue(isPositiveNumber(n));
JUnitでパラメータ化テストをすばやく作成する方法 | ソフトウェア品質向上・セキュリティツールのParasoft
パラメータ化テストは、データだけが異なる複数のテストケースを定義して実行するのによい方法です。ここでは、JUnitテストでよく使用される3つのフレームワークについて説明します。 ユニットテストを書くときは、メソッドの入力パラメーターと期待される結果をテストメソッド自体で初期化するのが一般的です。場合によっては、少数の入力の組み合わせだけで十分かもしれません。しかし、コードのすべての機能を検証するために膨大な値の組み合わせを使用しなければならない場合もあります。パラメータ化テストは、データだけが異なる複数のテストケースを定義して実行するのによい方法です。境界ケースを含むさまざまな値でコードの動作を検証できます。テストをパラメータ化すると、コードカバレッジが向上し、コードが期待どおりに機能しているという確信が得られます。 Javaには優れたパラメータ化フレームワークがいくつもあります。この記事
テストのためだけに`interface`を書きたくないでござる — KaoriYa
golangでテストのためだけにinterfaceを書くのが死ぬほど嫌だったので編み出した技を紹介します。 TL;DR テスト(=mock)のためだけにinterfaceは切りたくない 型エイリアスとビルドタグを組み合わせるとinterfaceがなくてもモックが作れる この手法に必要なモックを自動生成するプログラムを作った interfaceは本当に必要なシーンで使うべき Background 現在モックを使った単体テストは一般的です。 Javaでの例を挙げると、モックしたいコンポーネントについて予めinterfaceを定義しておき、モックではそのインターフェースを実装するのが定石です。 しかしgolangのinterfaceはJavaなどのそれとは若干性質が異なるため、テスト=モックのためだけにinterfaceを書くのはオーバーワーク気味です。 そうテストのためだけにinterface
やはり俺の「質 v.s. スピード」はまちがっている。 #eof2019 - 名前考えるの苦手
2019/10/31(金)に開催されたEngineering Organization Festival 2019 で @t_wada さんの「質とスピード」という講演を聞き、とても感銘を受けたのでメモ。 品質とスピードはトレード・オフの関係にある。どちらを優先するか？要バランスだ。 そう思っていた時期が私にもありました。 けど、そんなことはなかった！ ■追記 個人的な捉え方としては、 プロダクトを漸進的に成長させ、仮説検証ループするスピード上げようとすると、犠牲にした保守性があとで(意外とはやく1ヶ月後には)足枷になる。 保守性(テスト容易性、理解容易性、変更容易性)が低いとリードタイムが延びてスピードがどんどん落ちていくループをまわせなくなる。ってことかな、と思う。 スピードを上げようとしたのに、意外とはやくスピードが上がらなくなるジレンマ。 @t_wadaさんのスライド 素敵なグラレ
現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
猫800匹でSkype for Businessがフリーズ 絵文字処理の脆弱性に関する詳細、セキュリティ企業が公表 - ITmedia エンタープライズ
猫800匹でSkype for Businessがフリーズ 絵文字処理の脆弱性に関する詳細、セキュリティ企業が公表 Microsoftが11月の月例セキュリティ更新プログラムで修正した「Skype for Business」の脆弱性について、セキュリティ企業が猫の絵文字を使って実証した。 米Microsoftが2018年11月の月例セキュリティ更新プログラムで修正した「Skype for Business」の脆弱性について、この脆弱性を発見したドイツのセキュリティ企業SEC Consultが、ブログで詳細を公表した。 Skype for Businessのサービス妨害（DoS）の脆弱性（CVE-2018-8546）は、攻撃者が狙った相手に大量の絵文字を送信すると、相手のSkype for Businessクライアントが反応を停止してしまうというもの。 SEC Consultは猫の絵文字を使
idやclassを使ってテストを書くのは、もはやアンチパターンである - Qiita
いきなり結論を書くと、idやclassはスタイルのためのものなので、テストでそれを使うのはやめましょう。そして、カスタムデータ属性を使いましょう。(idやclassはスタイルのためだけではないという意見はごもっともです！しかし、主にとしてスタイルに使われるということでご了承頂いて以下の駄文に付き合って頂けると幸いです🙇) 先に断っておくと主にreactについての話で、JSXを前提とします。(手法はReactに限りませんが理由は後述) 2020/03/23 追記 この記事は1年以上前に書かれた記事なのでテストフレームワークとしてenzymeを使っていますが、現時点ではTesting Libraryの使用をオススメします。data-testid に対応するクエリを備えています。 React Testing Library · Testing Library はじめに ご存知の通り、ロジックと
Bashアプリケーションをテストする | POSTD
以前、bashスクリプトをテストする仕事に取り組んだことがあります。最初、Pythonユニットテストを使うことにしましたが、プロジェクトに外部技術を持ち込むのは気が進みませんでした。そこで、仕方なく、悪名高い bash で書かれたテスト用フレームワークを使いました。 既存ソリューションの概要 手に入るソリューションを探してGoogle検索しましたが、選択肢はほんの少ししかありませんでした。そのうちいくつかについて、詳しく見ていきましょう。 重要になるのは、どんな基準でしょうか？ 依存関係： bass のテスト用フレームワークを選ぶときに、 python 、 lua などのシステムパッケージも一緒に引きずり込むのは嫌ですね。 インストールの難しさ：継続的な開発の実装とTravis CIでの継続的な統合も仕事の1つだったので、私にとってインストールにかかる時間と手間数が妥当だということは、重要
よいユニットテストを書くには
テストを小さくする。適切なツールを使う。プログラマとテストがペアになる。これらは、よいユニットテストを書くための、Adrian Bolboaca氏からの提案だ。 ユニットテストは、プログラミングとテストが混ざり合ったものだ。プログラマは、テスタと共に作業することで、お互いに学び合い、視野を広げることができる。 Adrian Bolboaca氏は、Mozaic Worksの組織と技術に関するコーチであり、ヨーロッパテストカンファレンス 2017において、様々なタイプの自動テストについて話す予定だ。 InfoQは、このカンファレンスについて、Q&A、要約、記事で扱う。 [ヨーロッパテストカンファレンス]は、専門家や実践者が一緒に話し、学び、テスト技術を実践するところです。 私たちは、テストをもっと効果的にするために、先進的な新しい方法を詳しく調べ、より強いコミュニティに成長する基本的な方法を十
RSpec: Overview
Take very small stepsDon’t rush ahead with more code. Instead, add another example and let it guide you to what you have to do next. And don’t forget to take time to refactor your code before it gets messy. You should keep your code clean at every step of the way. View Documentation The BookEffective Testing with RSpec 3: Build Ruby Apps with ConfidenceThis definitive guide from RSpec’s lead devel
ソフトウェアテスト技術（実践編）
© NISHI, Yasuharu 同値分割ってなんだろう？ 九州ソフトウェアテスト勉強会（仮） Vol.7 2014/5/28（水） 電気通信大学 大学院情報理工学研究科 総合情報学専攻 経営情報学コース 西 康晴（Yasuharu.Nishi@uec.ac.jp, http://qualab.jp/） © NISHI, Yasuharu 2 Profile Assistant professor: the University of Electro-Communications, Japan (also providing consultancy service to industry on testing and TQM) President: Association of Software Test Engineering, Japan (ASTER) President: Jap
Refinements のスコープについて - Qiita
Refinements のスコープについて勉強した内容を紹介します RubyHiroba 2014 にて、このネタの LT をやりましたが、いまひとつまとまっていなかったので、まとめ直しました 朴訥なモンキーパッチ まず、Fixnum クラスにこういう変更を適用したいという事にします gem 'test-unit', '3.0.9' require 'test-unit' class Fixnum def to_hoge :hoge end remove_method :succ def succ :overridden end end class MonkeyTest < Test::Unit::TestCase sub_test_case '通常のメソッド呼び出しをすると' do test '上書きされた succ を呼び出せる' do assert { [:overridden, :
Rubyのテスティングフレームワークの歴史（2014年版） - 2014-11-06 - ククログ
2014年12月にRuby 2.2がリリースされる予定です1。 Ruby 2.2にはRuby 1.9.1のときに外されたtest-unitというテスティングフレームワークが再びバンドルされる予定です。Rubyのテスティングフレームワーク周りに詳しくない人にはよくわからない状況でしょう。そこで、Rubyのテスティングフレームワークの歴史を説明することで状況を整理します。 名称の整理 この説明の中ではたくさんのテスティングフレームワークが登場します。似たようなものもあるため、最初にテスティングフレームワークの名称を整理します。この説明の中で登場する名称は次の通りです。 RubyUnit Lapidary rubyunit Test::Unit test/unit test-unit miniunit minitest RSpec 違いがわかりますか？ざっくり説明すると次の通りです。 RubyU
テスト駆動開発（TDD）はもう終わっているのか？ Part 1 | POSTD
後編を公開しました（2014/10/8） これは、テスト駆動開発（TDD）とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2～3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の
blink(1) でテストの結果を表示するようにした話 - ちなみに
追記： Gem にしたのでご活用ください： http://rubygems.org/gems/guard-notifier-blink1 blink(1) を id:hxmasaki から1台譲ってもらったので Guard で走らせているテストの結果を通知するようにした。(一ヶ月くらい放置してしまってたのを今日やっと触れた。) すでにやっている人がいるだろうと探してみると、一応 guard-blink1 という Gem があった。しかし、これはただ blink1-tool を呼び出す部分をラップしてだけで、結果をファイルに書きだしてそれをさらにウォッチして通知のコードを呼び出すように自分で書かないといけない。つまり結果が出てからちょっとだけ遅延が発生する。これはすごい勢いでコードを書いているときにはどのテストの結果なのか分からないことがあってつらい。 仕方ないので自分で書くことにした。Gu
Martin Fowler's Bliki in Japanese - ユニットテスト
http://martinfowler.com/bliki/UnitTest.html 2014/5/5 ソフトウェア開発において、ユニットテスティングの話題になることが多い。私がプログラムを書きはじめて以来ずっと、ユニットテスティングという言葉はおなじみだった。 しかし、ソフトウェア開発用語の常として、ユニットテスティングという用語もきちんと定義できていない。 ユニットテスティングという用語の意味を実際よりも厳密にとらえてしまったせいで、混乱してしまっている人もよく見かける。 もちろんそれ以前からもユニットテスティングはやってきていたのだが、それを人前で公表したのは、Kent Beckと仕事をして Xunit系のツールを使い始めたころのことだった （この種のテストのことは、ユニットテスティングっていうより「xunitテスティング」って呼んだほうがいいと思うんだ）。 ユニットテスティングは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
移動しました - SmartHR Tech Blog
