🐷 What's Poku?A cross-platform test runner that brings the JavaScript essence back to testing. ⚡️ Quick Tutorials
![Poku](https://cdn-ak-scissors.b.st-hatena.com/image/square/f1c5a05a86cc2a86fb3dba08ad6dbe50692a4b5d/height=288;version=1;width=512/https%3A%2F%2Fpoku.io%2Fimg%2Fsocial.png)
🐷 What's Poku?A cross-platform test runner that brings the JavaScript essence back to testing. ⚡️ Quick Tutorials
Findy Team+でフロントエンドエンジニアをしている 川村(@peijun333)です。 Findy では、フロントエンドのコード品質と安定性を確保するために Jest などのテストフレームワークを積極的に活用しています。通常、Jest は CLI から実行してテスト結果をコンソールで確認しますが、コマンドを用意する手間や、テスト経過のデバッグのために都度 console.log などでその内容を確認しなければならずとても不便です。 そこで、今回はテストの自動化とリアルタイムなフィードバックを提供する JavaScript の統合テストツールである Wallaby.js を紹介します。Wallaby.js を導入することで、開発効率の向上が期待できます。 Wallaby.js とは? 前提条件 VS Code でテストの修正 Wallaby.js はリファクタリングに強い スナップシ
はじめに 株式会社hitocolorのKanonとしてはお初にお目にかかります。実は2024年2月からhitocolor様に副業先としてジョインさせていただいてます。 hitocolor様ではkokoroeというeラーニングサービスの開発をお手伝いしています! hitocolor様にjoin後、最初に着手した本格的な案件が今回の記事で書くStrykerの導入です。 Stryker自体は本業[1]の方の社内勉強会で登場したTOPICSで、その時から関心を持っていました。 本業の方ではそれよりも優先度の高いタスクがたくさんだったので導入の目処がなかったのですが、hitocolor様の方で提案したところ「いいね!」とおっしゃっていただき導入する運びになりました。 そして導入にあたっていろいろやったことを、「せっかくなので記事として公開してみよう!」とお話をいただき今に至ります。 Mutation
近日連投していた Next.js 記事のサンプルコードを公開しました。このサンプルコードを元に、私のフロントエンドディレクトリ構成・テスト観点を紹介します(あくまで執筆現在の脳内アウトプットになりますのでご了承ください) フロントエンドディレクトリ構成の事情 タイトルの「フロントエンドディレクトリ構成」をさす「Components」のディレクトリ構成は、いつも悩みのタネです。このモジュールシステムは「デザインシステム観点・アクセシビリティ観点・フロントエンド実装観点」の 3 つの観点が混在するため事情が複雑です。どうせ作るのなら「デザイナー・フロントエンド」どちらの開発基盤にもなりえる、盤石なモジュールシステムを目指したいですよね。 "AtomicDesign やめました"という声をたまに聞くのですが「デザインシステム的に捨てていいの?」と思うこともあるので、とくに要望がなければ、筆者は「
(社内用ドキュメントの公開版) テストのポリシー 前提として、ユニットテストを導入するコストを、限界まで低くすることを目指す。テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し、結果としてテスト不可能な巨大な雪だるまが完成する。こうなるとメンテコストが高いE2Eを大量に書かないといけなくなり、テストの実行時間が膨れ上がっていく。 そうなる前に、ユニットテストを書きやすい環境を維持し、ユニットテストとして問題を切り分けられるような環境を維持する。とにかく書きやすさを重視し、一つのユニットテストを書くオーバーヘッドを限界まで下げる。 最初の一つを早い段階で書く 自分の経験的には、ユニットとテストの最初の一つを書いたらあとは自然とその周辺で増えていく。サンプルがあったら人はコピペする。逆にいうと最初の一つを書かない限り一切書かれない。まず一つ用意するのが大事
2021/09/13 Open8 で発表したフロントエンドテストプラクティスの話です。
2021/03/05 ANDPAD TechLive #4 ANDPAD FrontEnd NOW!!
はじめに タイトルにもある通り、最近 Web アクセシビリティ (以下アクセシビリティ) の検証ツールを作っています。この記事では作るにあたったモチベーションや、現時点での機能、今後の展望についてまとめます。 モチベーション アクセシビリティを評価しようとすると Lighthouse にも付随する axe のようなツールを用いることが多いと思います。axe は WCAG 2.0 や WCAG 2.1 に則った数多くのルールを持ち、アクセシビリティに関する問題発見を支援してくれます。Lighthouse 以外では、axe をモジュールとして使えることはもちろん、Chrome の Extension などからも実行可能で、ユースケースに合わせた柔軟な利用ができます。 ただ、検証精度はどうかというと少し物足りなさを感じる部分があります。例えば以下のような例です。 <div role="butto
Enable collaborative test automation at any scale!Serenity/JS is an innovative test automation framework designed to help you create high-quality, business-focused test scenarios that interact with any interface of your system and produce comprehensive test reports that build trust between delivery teams and the business. Make your tests speak your languageSerenity/JS Screenplay Pattern helps you
CodeceptJS is opensource MIT licensed testing framework. Works with your favorite frontend frameworks → Scenario Driven Write acceptance tests from user's perspective. Make tests readable and easy to follow. Driver Agnostic Run your tests via Playwright, WebDriver, Puppeteer, TestCafe, Protractor, Appium. The code is the same. Learn More
平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識
これは FOLIO アドベントカレンダー2018 の23日目の記事です。 さて、昨日の@minodiskの記事でも触れられている通り、FOLIOのWebフロントエンドではStorybookを中心に据えた画像回帰テストを実践しています。 この記事では、FOLIOに画像回帰テストを導入するためにやってきた取り組みについて書いていきます。 大まかなワークフロー画像回帰テストのワークフローを簡単に説明します。 まずは対象となるコンポーネントについてStorybookでStoryを用意します。 StorybookこのStoryからCIで生成されるキャプチャ画像がスナップショットファイルとなります。 さて、仕様変更などによって上記のコンポーネントに変更が生じたとします。
「異能」ともいえる際立った能力や実績を持ち、まわりから一目置かれるエンジニアを1カ月に一人ずつ取り上げ、インタビューを掲載する。今月取り上げるのは、テスト駆動開発(TDD)の日本での第一人者として知られる和田卓人氏。JavaScriptのテストフレームワーク「power-assert」の作者でもある。最終回である今回は、power-assertの開発やテストに対する考え方などを聞いた。 (前回から続く) 自社製品を開発しようとワークフローエディターを自作して得たJavaScriptのスキルセットは、ぼくの大きな財産になりました。ワークフローエディターはかなり複雑なソフトウエアなので、テストコードなしでは開発は困難です。そこでJavaScriptのテストについてもいろいろ調べてみました。しかし、JavaScriptのテストの仕組みは当時はまだ全然発達しておらず、ほぼ手探り状態でした。 201
These docs are from an older version of sinon. Do you want the latest docs? API documentation - Sinon.JS - v18.0.0 This page contains the entire Sinon.JS API documentation along with brief introductions to the concepts Sinon implements. General setup Fakes Spies Stubs Mocks Spy calls Promises Fake timers Fake XHR and server JSON-P Assertions Matchers Sandboxes Utils Migration guides Migrating from
JavaScriptのテストダブル、定番Sinon.jsと新星testdouble.jsどっちを選ぶ? テストダブルは、難しいテストを簡単に実行できる代替コードです。 これまではSinon.jsがJavaScriptのテストダブルを作成するには不可欠なツールでしたが、最近、testdouble.jsという新しいライブラリーが話題になっています。Sinon.jsと同様の機能を備えていますが、いくつか違いがあります。 この記事では、Sinon.jsとtestdouble.jsのできることを紹介し、長所と短所を比較します。Sinon.jsがデファクトスタンダードのままになるか、それとも挑戦者がその座を勝ち取るのでしょうか? 注意:テストダブルをよく知らない人は、まず私が書いたSinon.jsチュートリアルを読むことをおすすめします。この記事で紹介する用語の理解を深めるのに役立ちます。 この記事で
TDD という用語を使うとテストおじさんがやってきて、それはそうじゃないとか色々言い出すと思うんだけど、それが趣旨ではないので勘弁して欲しい。予防線ここまで。 Puppeteer でテスト Puppeteer が世間的にも個人的にもブームだ。ヘッドレス Chrome を操ってクローリングしたりスクリーンショットを撮ったり色々出来る。 github.com で、あれこれと遊んでいるうちにテストに使えるんじゃね?ということに気づいたので実践してみたら快適だったという話。ブラウザ操作してテストというのは昔から Selenium というのがあり、こちらはクロスブラウザで出来たりするんだけどまあ大掛かりでだるさを感じてしまう。メリットデメリットの比較はさておき、どうせならナウいやつを使ってみたい。よし使おう。 何をテストするか 普段から画面を見ながら開発しているので、どこに何が表示されているべきとい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く