Angular v19 will make standalone: true the default for components, directives, and pipes.
Angular Blog
Angular v19 will make standalone: true the default for components, directives, and pipes.
モックは必要悪で、しないにこしたことはない - blog.8-p.info
Mockito や gomock が使いやすいせいか、単体テストというのはモックするものである、という思い込みがあるのか、人々がモックしすぎているのを時折みかける。 モックは必要悪で、しないにこしたことはない。外部の API サーバーとかはガンガン叩くわけにもいかないけれど、ファイル読み書きくらいは、実際にファイルを作ったり消したりしてしまっていい。/etc/passwd を消すとか、1GB のファイルを作るとかだと難しいかもしれないけれど、その場合でも、パスのプレフィックスを指定できるようにして、一時ディレクトリの中の etc/passwd を使うとか、ファイルサイズを指定できるようにするとか、逃げ道はいくつもある。そこを飛ばして「ファイル操作は一律モックしましょう」とか頑張りだすと辛いことになりがちだ。 モックの一番の問題は、本番とテストで違うコードが走ることで、これは自動テストの価値
フロントエンドテストプラクティス in open 8
2021/09/13 Open8 で発表したフロントエンドテストプラクティスの話です。
ローコードテスト自動化ツールの mabl がすごい
というのを使っていて思ったのでレポを書いていきます。 mabl とは - 基本的な機能 ざっくり言うと E2E テストをお手軽にメンテできるツールです。 こんな感じでポチポチ画面を操作していくと、それで実行したアクション(ボタンやリンクをクリックするなど)を自動で記録してくれて、E2E のテストを作成することが出来ます。 コードを書かずに E2E テストをサクッと作れちゃうのが魅力な訳ですが、それだけではありません。そんなすごいところを紹介していこうと思います。 mabl のここがすごい Auto Healing 何やら回復魔法みたいな感じでかっこいいですが、何かというと E2E テストがコケるようになった時に自動で修復してくれる機能です。 例えばボタンの位置が変わってしまっても、同じ文脈であろうボタンを自動で探して修復したりしてくれます。 E2E での辛さといえば、やはりテストのメンテナ
Strykerを使ってTypeScriptでMutation Testingする
概要 JavaScript/TypeScript向けのMutation Testing FrameworkであるStryker-jsがいい感じになってきたので紹介してみます。簡単な紹介のみです。 対象読者 Strykerの概要を知りたい人 Mutation Testingよく知らないJSer/TSer Mutation Testing導入したいけどJS/TS用のツールが見つからなかった人 Mutation Testingとは テスト対象のコードを変更(Mutate)するミュータントを仕込み、Unit Testが正しくそれらのミュータントを退治できるか測定するものです。 一般的には退治できた割合が高いほど意味のあるUnit Testを書いていると言えます。 Wikipediaの項目にもある通りFuzzingの一種とも言えます。 Mutation Testing自体はGoogleが論文出してた
RSpecの作者が振り返る歴史（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: History of RSpec – Steven R. Baker 原文公開日: 2021/05/09 著者: Steven R. Baker 日本語タイトルは内容に即したものにしました。 私がTDD（テスト駆動開発）をチームで教え始めたのは2001年のことでした。当時のTDDはまだかなり新しい概念でしたので、テストを自動化したチームもほとんどなく、XP（エクストリームプログラミング）やTDDについて聞いたことがある人も皆無でした。テストを最初に書くことで設計を進めるという概念は当時まったく知られていなかったので、TDDを理解するのに皆とても苦労していました（20年経った今でも、この事実が完全に変わったとは言えません）。 思い返せば、あの当時は厳しい状況でした。最善を尽くしてTDDの概念を説明し、どうにかしてチームの関心を惹こう
N 予備校に Visual Regression Testing を導入した話 + tips - ドワンゴ教育サービス開発者ブログ
こんにちは。N 予備校 Web フロントエンド開発チームの berlysia です。 N 予備校の Web フロントエンド開発に、 Storycap + reg-suit による Visual Regression Testing を導入しました。設定の工夫から、設定中や運用してしばらくの間に実際に発生したハマりどころを挙げ、簡単に注意点や対処例を紹介します。 背景 N予備校について N 予備校はドワンゴが提供するオンライン学習サービスです。大学受験対策、プログラミング、Webデザイン、機械学習など多様なコースがあります。オンラインでの利用に合わせた教材や、講師が生放送で行う授業、受講者同士でも質問し教えあえるフォーラムを備えています。 www.nnn.ed.nico 周辺状況 N 予備校の Web フロントエンド開発とそれを取り巻く状況には、次のような特徴があります。 React による
同じソースツリーでテストが通っていたらテストをスキップする | おそらくはそれさえも平凡な日々
tl;dr git rev-parse HEAD^{tree} でツリーオブジェクトのハッシュ値が取れるので、ブランチが異なる場合でも同じソースツリーであるかどうかを判定できます。 これを利用して、すでにテストを通ったtreeのハッシュ値をどこかに記録しておいて、同一のソースツリーに対するテストをスキップできます。 本題 よく使われている、develop/mainブランチ運用をしている場合に、ちょっとした修正を本番に入れたい場合には以下のようなフローを踏むことになるでしょう。 featureブランチをdevelopブランチの先頭から切って修正を作ってテストが通るのを待つ developブランチにfeatureブランチにマージしてテストが通るのを待つ mainブランチにdevelopブランチをマージしてテストが通ったらdeployする さて、この時、他の作業が混ざらない限りにおいては1,2,
一瞬でテストを Test2::V0 対応させる - 私が歌川ですScrapbox支店
Test::Deep, Test::Fatal, Test::Mock::Guard などが持つ機能を内包
qrcode.react とスナップショットテストの相性が最高すぎた - 経験は何よりも饒舌
qrcode.reactは、その名の通りQRコードを生成してくれるReactコンポーネントだ。 github.com ファイル構成はsrc/index.jsでゴリゴリ計算というか文字列を算出し、コンポーネントを返す構成だった。 テストがなかったので、テストを追加したかったのだが、何に対してテストを追加すればよいのかわからず、しばらく放置していた。 convertStr関数やgeneratePath関数の入力と出力に対する単体テストを追加しようと思ったけれど、あまり恩恵はないように思えた。 qrcode.react/index.js at 6aeb42abc26ffecc868b630b6ad8f507d2125813 · zpao/qrcode.react · GitHub qrcode.react/index.js at 6aeb42abc26ffecc868b630b6ad8f507d
PerlでスナップショットテストをするTest::Snapshotのご紹介 - Masteries
このエントリは, ｢Perl Advent Calendar 2020｣の9日目の記事です. qiita.com 昨日のエントリは, id:xtetsuji さんの｢xargs や find と合わせて使う・代わりに使う Perl｣でした. qiita.com 実は最近異動をしていた id:papix です. 異動後もPerlをモリモリ書いている日々ですが, 移動先のチームのプロダクトで同僚の id:mizdra が導入していた Test::Snapshot が便利だったので紹介します. metacpan.org Test::Snapshot Test::Snapshotは, その名の通り｢スナップショットテスト｣を提供するモジュールです. スナップショットテストとは, 予め｢スナップショット｣と呼ばれる期待値を生成しておき, テストを実行する際には実行結果とスナップショットを比較してテス
現役テスト（QA）エンジニアが仕事内容について説明してみる。 - GMO Research & AI Tech Blog
いやー、今年のアニメも面白いな～ ひぐらしのなく頃に～業～ もやり始めたし、次回も視聴してからでいいか、ブログ書くの。締め切りいつだっけ。まだ先だろうきっと・・・。 ん？誰か来たかな。 どうぞー。 ／|∧_∧| ||. (･ω･#´| ＜記事終わったの？、ねえもう納期なんだけど。 ||oと. Ｕ| 納期守って言ったよな？ あぁぁん？ || |（__）Ｊ| ||／彡￣ ｶﾞﾁｬ げっ！・・いや、 あ、 はい。どうも、編集長の益山氏。どうしたんですか。こんな早朝から。。 え？・・・なに？ブログ？締め切り？（ ＾ω＾）・・・ あーーうん、うん 書いてるよ。ちゃんと。 はっはっ・・・へぇあっ。 益山氏「嘘だっっ！！」・・・ やべぇ・・バレてる。。。 はい？ え？納期間に合わないだろだって？！ はっ！はっ！はっ！いやいや間に合いますって。 ・・ん？益山氏、いまどこから、それ出した。え？家から
自動テストのスタブ・スパイ・モックの違い
ソフトウェアの自動テストで使う代品オブジェクト――いわゆる「 テストダブル 」の種類についてまとめました。 タイトルには「スタブ」「スパイ」「モック」の 3 つだけをあげていますが、他にも「フェイクオブジェクト」と「ダミーオブジェクト」に言及しています。 お断り この記事の説明は書籍『 xUnit Test Patterns: Refactoring Test Code 』（ Gerard Meszaros 著）の定義に基づいています。 このあたりの用語の定義は人や流派によって異なります。この記事の説明が常に正しいわけではありません。 テストダブルの全体像 テストダブルの分類は次のようになっています。 テストスタブ・テストスパイ・モックオブジェクト等のテスト用の道具をまとめてテストダブルと呼びます。 テストダブルとはプログラムの中でオブジェクトや関数やモジュール（以下これらをまとめて「コン
Property Based Testing でドメインロジックをテストする
class: center, middle # Property Based Testing で<br />ドメインロジックを<br />テストする Scala関西Summit 2017/09/09 --- class: left, middle ## 自己紹介 * 中村 学(Nakamura Manabu) * [@gakuzzzz](https://twitter.com/gakuzzzz) * Tech to Value 代表取締役 * Opt Technologies 技術顧問 <img src="./images/opt_logo_1.jpg" alt="Opt Technologies" width="450" style="margin-left: 0px" /> * f-code チーフアーキテクト <img src="./images/f-code_logo.png" a
にひりずむ::しんぷる - local $Test::Builder::Level = $Test::Builder::Level + 1 するのに飽きたので Test::Level 書いた
一連のテストを関数にして実行するのはよくあると思うんですが、その時にエラーが発生した箇所を正確に知るには、$Test::Builder::Level っていうのをインクリしてやらなきゃいけません。 例えば、以下のようなテストがあったとします。 1| use Test::More; 2| 3| sub some_test { 4| my $input = shift; 5| ok $input % 2 == 0, 'even number'; 6| } 7| 8| some_test(1); 9| some_test(2); 10| some_test(3); 11| 12| done_testing; わかりやすさのために行数を書いてみました。 これを実行した結果は以下のようになります。 not ok 1 - even number # Failed test 'even number'
Xvfb を使って仮想ディスプレイを作る - CUBE SUGAR CONTAINER
Xvfb (X virtual framebuffer) は X Window System の仮想ディスプレイを作ることのできるソフトウェア。 これを使うと実際にスクリーンがない状態でも GUI が必要なソフトウェアを使えるようになる。 今回使う環境には CentOS7 を選んだ。 $ cat /etc/redhat-release CentOS Linux release 7.2.1511 (Core) $ uname -r 3.10.0-327.3.1.el7.x86_64 下準備 まずは GUI を必要とするソフトウェアとして Firefox をインストールしておく。 $ sudo yum -y install firefox ipa-{,p}gothic-fonts ipa-{,p}mincho-fonts 次にランレベルを確認しておく。 単なるマルチユーザモードなので、通常であ
テスト環境 – React
このドキュメントではあなたの環境に影響する要素や、いくつかのシナリオにおける推奨事項について概説します。 テストランナー Jest、mocha、ava のようなテストランナーを使えば、標準的な JavaScript を使ってテストスイートを書き、開発プロセスの一環として実行できるようにできます。加えて、テストスイートは継続的インテグレーションの一部としても実行されます。 Jest は React プロジェクトとの広範な互換性を有しており、モジュールやタイマーのモック、jsdom のサポートを有しています。Create React App を使っている場合、Jest は有用なデフォルト値とともに追加設定なしでインストールされます。 mocha のようなライブラリは実際のブラウザ環境でうまく動作するため、それが必要なテストでは有用でしょう。 End-to-end テストは複数のページにまたがる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Interaction Testing sneak peek
GitHub - tschaub/mock-fs: Configurable mock for the fs module
jsdom vs. PhantomJS