testing-library でユーザの気持ちになって書くフロントエンドのテスト
TL;DR フロントエンドのテストが壊れやすく要因の一つは、ユーザがどのようにソフトウェアを使うかをクエリに反映できていないからかも testing-library はソフトウェアを使うユーザの気持ちを反映させやすいようにクエリの優先度をつけていて、それに従うほうがいい 優先度の低いクエリも役に立つことがある 運用しているアクセシビリティなどの実装のガイドラインに沿うようなテストを作るとき アクセシビリティの低い実装をリファクタリングするためのテストを作るとき はじめに フロントエンドのテストに用いるツールとして testing-library が知られています。testing-library は提供しているクエリに優先度をつけています。この優先度は、どういう基準でつけられているのでしょうか。 この記事では、 testing-library のガイドを読みながら、クエリの優先度を「ユーザの
@open-wc/testing
import { fixture, html } from '@open-wc/testing'; describe('my-test', () => { it('works', async () => { const el = await fixture(html` <my-element></my-element> `); }); }); import { expect, fixture, html } from '@open-wc/testing'; describe('Plugin - semantic-dom-diff', () => { it('can semantically compare full dom trees', async () => { const el = await fixture(`<div><!-- comment --><h1>${'Hey'} </
Twelve Days of Front End Testing
Amy Kapernick sings us through numerous ways of improving the robustness and reliability of our front end code with a comprehensive rundown of ideas, tools, and resources. The girls and boys won’t get any toys until all the tests are passing. Anyone who’s spoken to me at some point in November may get the impression that I’m a bit of a grinch. But don’t get me wrong, I love Christmas, I love decor
Testing the accessibility of pattern libraries
When assessing how accessible your website or app is, auditors will likely want to look at whole pages. But perhaps most of what you are working on is individual components. I mean, this is how lots of companies work nowadays. Can pattern libraries be tested for accessibility? And if so, what do we test? In this post I will address those questions and look at accessibility testing in different lev
Web アクセシビリティ向け Node.js 製の自動チェックツールや DevTools 用の拡張機能など
アクセシビリティを担保するプロセス作り この記事は Web Accessibility Advent Calendar 2016 - Adventar の 12 日目の記事です。 UI 実装の再考と a11y - Frontrend Vol.8 LT でも述べましたが、Accessibility is a Process, Not a Project ということでアクセシビリティ対応するプロジェクトではなく、アクセシビリティを担保するプロセスを作りましょうということで、チェックツールをいくつか並べて俯瞰してみます。対象読者は自分と同じようなクライアントサイドの Web アプリケーション屋さんということにしておきます。 ちなみにアクセシビリティ評価ツールについては 3 日目のアクセシビリティ方針、報告書、試験支援ツールa11ycのご紹介 (Web Accessibility Advent C
Deque Launches aXe 2.0
Introducing aXe 2.0! We’re excited to announce the launch of aXe 2.0, an updated version of our open source accessibility testing engine! Since the initial announcement last year, we’ve made improvements to many rules and checks, introduced a plugin system, added configuration options, and enhanced our project’s infrastructure. We’ve seen adoption among developers and QA’s with our Chrome and Fire
Ensuring high-quality browser accessibility with automation
Over the past few weeks, we’ve shown how Microsoft Edge has been rearchitected to empower developers to build more accessible experiences on the Web with HTML5 and UIA. To support this work, we need to ensure that accessibility is not accidentally regressed as we make other improvements to the browser. Testing the accessibility implementation of a browser on Windows used to require downloading the
iOS Automated Tests with UIAutomation
Updated on 2013/04/08: Added command-line for Xcode >= 4.5, how to take screenshots and launch local scripts. Quick introduction Automated tests are very useful to test your app “while you sleep”. It enables you to quickly track regressions and performance issues, and also develop new features without worrying to break your app. Since iOS 4.0, Apple has released a framework called UIAutomation, wh
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - NickColley/jest-axe: Custom Jest matcher for aXe for testing accessibility ♿️🃏
GitHub - dequelabs/axe-core: Accessibility engine for automated Web UI testing
GitHub - pa11y/pa11y: Pa11y is your automated accessibility testing pal