音を鳴らす
JavaScriptで音を鳴らすことができます。ご自分の耳が何Hzまで聞こえるか試してみてください（23000Hzまで聞こえたというかたがおられたので24000Hzまでに増やしてみました）。 1000 Hz Stop 4000 Hz 8000 Hz 10000 Hz 11000 Hz 12000 Hz 13000 Hz 14000 Hz 15000 Hz 16000 Hz 17000 Hz 18000 Hz 19000 Hz 20000 Hz 21000 Hz 22000 Hz 23000 Hz 24000 Hz 仕組みはソースを見てください。ほぼChatGPT 4oに書いてもらいました。最初はボタンの数が少なかったこともあってChatGPTはボタン一つ一つに id を付けていたのですが、ボタンの数が増えると厄介なので、this を使ってくださいと指示したら、こうなりました。
Vitest公式になったeslint-plugin-vitestを導入して、適切なVitestのお作法を学んでみる
import vitest from "@vitest/eslint-plugin"; export default [ { files: ["tests/**"], // or any other pattern plugins: { vitest }, rules: { ...vitest.configs.recommended.rules, // you can also use vitest.configs.all.rules to enable all rules + // e.g. 'vitest/no-test-return-statement': 'error', + "vitest/max-nested-describe": ["error", { "max": 1 }] // you can also modify rules' behavior using optio
Node.jsで型安全な環境変数を扱うスニペット
Node.js で型安全な環境変数を扱うスニペットを作りました。 next devのようなアプリケーションの起動、Playwright でのテストなどコマンドごとに渡したい環境変数のセットが異なるケースがあります。 この場合に環境変数をまとめたものを定義して、それをコマンドごとに読み込むセットを変えたいことがあります。 次のようにベタ書きしてもいいのですが、渡したい環境変数が増えると管理が大変になります。 NEXT_PUBLIC_LOCALHOST_URL=http://localhost:3000 NEXT_PUBLIC_API_URL=http://localhost:3001 NEXT_PUBLIC_IS_TEST_MODE=false FOO="bar" next dev そのため、.envのような環境変数をまとめたファイルを使いたくなります。 Node.js は--env-fil
Poku
🐷 What's Poku?A cross-platform test runner that brings the JavaScript essence back to testing. ⚡️ Quick Tutorials
テストコード品質を高めるためにJS向けMutation Testingライブラリ・Strykerを実戦導入してみた
はじめに 株式会社hitocolorのKanonとしてはお初にお目にかかります。実は2024年2月からhitocolor様に副業先としてジョインさせていただいてます。 hitocolor様ではkokoroeというeラーニングサービスの開発をお手伝いしています！ hitocolor様にjoin後、最初に着手した本格的な案件が今回の記事で書くStrykerの導入です。 Stryker自体は本業[1]の方の社内勉強会で登場したTOPICSで、その時から関心を持っていました。 本業の方ではそれよりも優先度の高いタスクがたくさんだったので導入の目処がなかったのですが、hitocolor様の方で提案したところ「いいね！」とおっしゃっていただき導入する運びになりました。 そして導入にあたっていろいろやったことを、「せっかくなので記事として公開してみよう！」とお話をいただき今に至ります。 Mutation
私のフロントエンドディレクトリ構成・テスト観点 2022
近日連投していた Next.js 記事のサンプルコードを公開しました。このサンプルコードを元に、私のフロントエンドディレクトリ構成・テスト観点を紹介します（あくまで執筆現在の脳内アウトプットになりますのでご了承ください） フロントエンドディレクトリ構成の事情 タイトルの「フロントエンドディレクトリ構成」をさす「Components」のディレクトリ構成は、いつも悩みのタネです。このモジュールシステムは「デザインシステム観点・アクセシビリティ観点・フロントエンド実装観点」の 3 つの観点が混在するため事情が複雑です。どうせ作るのなら「デザイナー・フロントエンド」どちらの開発基盤にもなりえる、盤石なモジュールシステムを目指したいですよね。 "AtomicDesign やめました"という声をたまに聞くのですが「デザインシステム的に捨てていいの？」と思うこともあるので、とくに要望がなければ、筆者は「
(自分の) JavaScript のユニットテストの書き方
(社内用ドキュメントの公開版) テストのポリシー 前提として、ユニットテストを導入するコストを、限界まで低くすることを目指す。テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し、結果としてテスト不可能な巨大な雪だるまが完成する。こうなるとメンテコストが高いE2Eを大量に書かないといけなくなり、テストの実行時間が膨れ上がっていく。 そうなる前に、ユニットテストを書きやすい環境を維持し、ユニットテストとして問題を切り分けられるような環境を維持する。とにかく書きやすさを重視し、一つのユニットテストを書くオーバーヘッドを限界まで下げる。 最初の一つを早い段階で書く 自分の経験的には、ユニットとテストの最初の一つを書いたらあとは自然とその周辺で増えていく。サンプルがあったら人はコピペする。逆にいうと最初の一つを書かない限り一切書かれない。まず一つ用意するのが大事
フロントエンドテストプラクティス in open 8
2021/09/13 Open8 で発表したフロントエンドテストプラクティスの話です。
VRTやってますか？reg-suitですか？
2021/03/05 ANDPAD TechLive #4 ANDPAD FrontEnd NOW!!
Web アクセシビリティの検証ツール acot を作ってる
はじめに# タイトルにもある通り、最近 Web アクセシビリティ (以下アクセシビリティ) の検証ツールを作っています。この記事では作るにあたったモチベーションや、現時点での機能、今後の展望についてまとめます。 モチベーション# アクセシビリティを評価しようとすると Lighthouse にも付随する axe のようなツールを用いることが多いと思います。axe は WCAG 2.0 や WCAG 2.1 に則った数多くのルールを持ち、アクセシビリティに関する問題発見を支援してくれます。Lighthouse 以外では、axe をモジュールとして使えることはもちろん、Chrome の Extension などからも実行可能で、ユースケースに合わせた柔軟な利用ができます。 ただ、検証精度はどうかというと少し物足りなさを感じる部分があります。例えば以下のような例です。 <div role="but
Serenity/JS - Collaborative test automation at any scale
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. Test automation aligned with your business Serenity/JS helps you create auto
CodeceptJS
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
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
GitHub - ehmicky/test-each: 🤖 Repeat tests. Repeat tests. Repeat tests.
// The examples use Ava but any test runner works (Jest, Mocha, Jasmine, etc.) import test from 'ava' import multiply from './multiply.js' import { each } from 'test-each' // The code we are testing // Repeat test using different inputs and expected outputs each( [ { first: 2, second: 2, output: 4 }, { first: 3, second: 3, output: 9 }, ], ({ title }, { first, second, output }) => { // Test titles
フロントエンドの負債と向き合う - mizchi's blog
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
テストでモックできなくて困るNode.jsのモジュールの書き方 - console.lealog();
こういう書き方にしてしまったせいで、テストの時にうまくモックできず困ったよというメモ。 問題のコード こういうやつ。 function foo(id) { bar(id); // ... } function bar(id) { // some heavy logics... } module.exports = { foo, bar, }; モジュール内が関数だけで構成されてるのは○。 ただし、テスト的には都合が悪い。 何に困るか テストでこの関数をモックしたい・・って時に困る。 さっきのコード例で、`foo()`をテストするときに、`bar()`をモックしたいとする。 jestだとこんな風にするはず。 const mod = require('../mod'); describe('foo test', () => { let barSpy; beforeEach(() => { ba
少人数でのフロントエンド開発をクイックに進めるために - Qiita
この記事は 第2のドワンゴ Advent Calendar 2017 7日目の記事です。 昨日の記事は@yue82さんでRTL設計スタイルガイドのアンチパターンをやってみたでした こんにちは。ニコニコ静画でフロントエンド開発を行っているnagisioです。 今年も冬コミに落ちてしまいました 去年の記事はRe:ゼロから始めるElectron開発生活でした。Electronに関して、残念ながら最近はあまり書いてないのですが、Reactは既に趣味でも仕事でも必須なフレームワークとなりました。 本記事ではそんなReactを用いたプロダクト開発について、どのように開発を進めていくのかを追っていきます。 はじめに（宣伝枠） ニコニコ静画チームにおいて、フロントエンドでの新規開発は基本的に少人数（１〜２人程度）で行っています。比較的小規模な開発が多く、例えば直近でリリースしたのがニコニコ漫画@C93です
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - angular/tsickle: Tsickle — TypeScript to Closure Translator
1年間単体テストを書き続けた現場から送る Vue Component のテスト / Vue Component Test - Speaker Deck
JavaScriptのE2Eフレームワークを触ってみる
