Astro + playwright + huskyでポートフォリオサイトを作ってみる
と、こんな感じになりました。 どうやってポートフォリオ作っていったか イチから Astro を勉強してやっていっても良かったのですが、習うより慣れろという形で、まずは先人たちのテンプレを参考にさせていただいて、自分なりに改造していく感じで実装していきました。 Astro テンプレートを選ぶ Astro 初心者でも簡単にプロジェクトを作れるように様々な用途のテンプレートが用意されていて非常にわかりやすいです。 Portfolioなのでなるべくシンプルに、カラーテーマを手軽に変更できて、コンテンツを.mdxで記述したかったので、Astro Modern Personal Websiteというテーマを使わせていただきました。 必要ない情報を落とす 今回選んだテーマでは、blog だったり store ページにも対応できるように、様々なページが実装されています。 今回はあくまでもポートフォリオなの
k6を使いこなしてみよう - 生涯未熟
この記事は MIXI DEVELOPERS Advent Calendar 2022 6 日目の記事です。 負荷試験を行う機会が年に何度かあるのですが、以前まではvegetaを使っていましたがちょっと高めの負荷をかけた時の挙動がよろしくなく、k6を試してみたところ不満が無かったので最近はk6を常用しています。 そんなk6をもうちょっと使いこなすために色々とまとめてみようかと思います。 k6とは？ Grafana Labsが開発した負荷ツール。 github.com ツール自体はGo製で、負荷シナリオをJavaScriptで書きます。 負荷シナリオはk6 Browser RecorderというChrome拡張を使えばブラウジングしているだけで作成可能で、k6 Cloudを使ったWeb上でのシナリオ作成・管理・実行が可能です。 わざわざGitHub上でシナリオを管理しなくてもいいというのは個人
リーダブルテストコード - Qiita
はじめに よく言われるように、ソースコードというものは書かれることよりも読まれることの方が多く、それゆえ読みやすいコードを書くということが非常に重要です。それはテストコードにおいても同様であり、プロダクトコードと同等に資産として扱う必要があります。 テストコードは具体的な値を用いて記述し、また複数の変数の値の組み合わせでテストケースを起こすため、プロダクトコードと比べて冗長になりがちです。 書籍『リーダブルコード』の14章でもテストコードの読みやすさについて触れられていますが、本稿では読みづらいテストコードをリファクタリングして読みやすくするためのテクニックを紹介したいと思います。 なおサンプルコードはJavaScriptで記述されており、そのテストコードはJest1を用いて書いています。 ソースコードはGitHubにあります。 リファクタリング(その壱) 以下の、決して読みやすいとはいえ
Testing JavaScript をやってみたら学びがあって良かった話 - Adwaysエンジニアブログ
こんにちは。リファクタリングが大好きなフロントエンドおじさん梅津です。 自信を持ってリファクタリングするには信頼できる自動テストが必要ですよね。 じゃあ信頼できる自動テストとはなんだろう？どう書いたらいいんだろう？と考えていました。 とくにコンポーネントを含む UI テストに対しての悩みが強かったです。 そんなときに出会ったのが Testing JavaScript です。 この記事ではその Testing JavaScript の紹介をしたいと思います。 Testing JavaScript とは Testing JavaScript は PayPal のエンジニアである Kent C. Dodds によって作成された教材です。 ページを開いてすぐ目に飛び込んでくるテスティングトロフィーが特徴的ですね。 Testing JavaScript では、ここに記されている Static, Un
The perfect unit test - Jack Franklin
April 12, 2019The perfect unit testThere's a common theme I find with people who tell me that they don't find unit testing useful, and it's normally that they are writing bad tests. This is completely understandable, particularly if you're newer to unit testing. It's hard to write good tests and it takes practice to get there. All the things we're going to talk about today were learned the hard wa
我が名は神龍……どんなテストもひとつだけ自動化してやろう - Qiita
『我が名は神龍……どんなテストもひとつだけ自動化してやろう』 じゃ、じゃあ！このブラウザテストを自動化してください！ Chromeで https://kids.yahoo.co.jp/ にアクセスして 検索ワードに ねこ と入力して さがすをクリックして 検索結果にネコ - Wikipedia が含まれていることを確認して 検索結果に 買い方 を追加して さがすをクリックして 探しているのは「猫の飼い方」？と表示されることを確認して クリックすると猫の飼い方で再検索されて 検索ボックスを不倫で上書きして さがすをクリックして このページは表示できませんと出ていることを確認 『よかろう……たやすい願いだ』 まずはライブラリのインストールと初期設定をしてやろう…… # [ライブラリのインストール] # CodeceptJSとPuppeteerをインストールします。nodeとnpmが必要ですので
PhantomJSの開発が終了しリポジトリがアーカイブ化された
QtWebKitをベースにしたヘッドレスブラウザであるPhantomJSの開発が終了され、2018年6月2日にリポジトリもアーカイブされました。 ariya/phantomjs: Scriptable Headless Browser 以前にもお伝えしていましたが、PhantomJSはQtWebKitをベースにしていて安定版が利用しているバージョンも古いままでした。 また、QtWebKitの新しいバージョンへアップデートを行うベータ版も開発されていましたが、Headless Chromiumが公開されたことや個人でPhantomJSのメンテナンスを続けていくの難しいという問題もあり開発は停止していました。 2017-05-03のJS: Headless Chrome/FirefoxとPhantomJS/SlimerJS、ES modules - JSer.info 2017-09-05のJ
JavaScriptユニットテストの理想と現実
Talk at 関西Node学園 梅田キャンパス 1時限目 https://nodejs.connpass.com/event/82614/
フロントエンドの負債と向き合う - mizchi's blog
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
Webブラウザの操作をJavaScriptで自動化。Headless Chromeのフレームワーク「Puppeteer」がバージョン1.0に到達。ChromeのDevToolsチームが開発
UIを持たずスクリプトから操作可能なWebブラウザのHeadless Chromeを利用するためのフレームワーク「Puppeteer」がバージョン1.0に到達した。Webアプリケーションの自動テストなどに利用可能だ。 GoogleのWebブラウザ「Chrome」は、ユーザーインターフェイスを持たずコマンドラインやリモートデバッグ機能を通じてWebブラウザを操作できる「Headless Chrome」機能を備えています。この機能は2017年6月にリリースされた「Chrome 59」から実現されたものです。 Headless Chromeを利用すると人間がWebブラウザをマウスやキーボードで操作することなく、プログラムでHeadless Chromeを起動し、特定のWebページを読み込み、画面キャプチャの取得や、指定された場所をクリックし、値を入力し結果を取得する、といった操作を自動的に行わせ
ヘッドレスChromeの自動化ツール「Chromeless」を使って自動テストを実施する #serverless #adventcalendar | DevelopersIO
ヘッドレスChromeでシンプルに自動テストを行う Google Chromeのバージョン59から標準搭載された、ヘッドレスモード（GUIがないモード）。コマンドラインからヘッドレスブラウザを立ち上げることができ、スクリーンショットの撮影を行ったりDOMを出力したりすることができます。自動化の可能性に満ち溢れた機能です。 ヘッドレスChromeの導入については、次の公式ドキュメントが詳しいです。 ヘッドレス Chrome ことはじめ | Web | Google Developers ドキュメントを読んでいただくと分かると思いますが、様々なことが可能なため指示の記述が少し冗長な面があります。 そこでヘッドレスChromeを用いた自動化処理をシンプルにすることに特化した便利ツール「Chromeless」を紹介します。 なお、今回実装したソースコードはGitHubで公開しています。わせ
一休.comのJavaScriptユニットテスト環境 - 一休.com Developers Blog
この記事は一休.com Advent Calenrad 2017の2日目です。 宿泊事業本部フロントエンドエンジニアの宇都宮です。 一休.comの宿泊予約サービス（以下、一休）では、以下のようなスタックでWebフロントエンドの開発を行っています。 言語：ES 2017 ライブラリ・フレームワーク：古いところはjQuery、新しいところはVue.js ビルドパイプライン：Webpack + Babel 一休では、主要導線のE2Eテストは整備されています*1。一方、フロントエンド(JavaScript)のユニットテストは発展途上といったところです。 本記事では、一休のJSユニットテスト環境の変遷と現状について紹介します。 AVA 2017年4月の時点で、一休のJSユニットテスト環境は以下のような状況でした。 テスティングフレームワーク：AVA Babelでビルドされているコード：1,000行程
2017年JavaScriptのテスト概論 | POSTD
本稿は、JavaScriptのテストについて最も重要な根拠、用語、ツール、アプローチなどの知識を身に着けることを目的とした簡略版ガイドブックです。本稿で検討する数々の側面に関する最新の秀逸な記事も紹介しつつ、私たちが経験的に得たことも多少付け加えたいと思います。 Facebookによるテスト用フレームワークであるJestのロゴをご覧ください。 見てお分かりのように、このフレームワークは「苦痛のない」JavaScriptのテストをスローガンに掲げています。しかし、 “次のように言う人” もいます。 苦痛のないテストなんてあり得ない。 実際、Facebookはこのスローガンを掲げるだけの素晴らしい理由があります。一般的にJSのデベロッパは Webサイトのテストにあまり満足していません 。JSのテストには制限があり、実装が難しく、低速である傾向があります。 一方、正しい戦略を立てて適切にツールを
ヘッドレスブラウザ(Chrome)を使ってSPAをスクレイピングする - Qiita
一般的なスクレイピング手法とその問題点 スクレイピングというと、HTTPクライアントライブラリを用いてHTML取得し、HTML/XMLパーサーで解析するというのが一般的だと思います。 この手法の場合、以下の場合にうまく処理できません。 ターゲットのページがJavaScriptにより動的にDOMを操作する場合 HTML/XMLパーサーが取得したHTMLを正しく解釈できない場合(正しくないHTMLでもブラウザはなんとか処理するが、パーサーライブラリは正確なHTMLでないと処理できないことがある) 特に問題になるのは前者でしょう。最近のWebサイトではJavaScriptでDOMを操作することは珍しくなくなってきています。SPAであればなおさら難しく、もはやこういった手法によるスクレイピングは不可能でしょう。 ヘッドレスブラウザによるスクレイピング 動的なDOMやパーサーがうまく解釈できないとい
コードの複雑さ - テスタブルJavaScript - 野次馬エンジニア道
テスト熱が高まっているので自宅で下記の本を発掘。放置していた間に本書でメインに取り上げられているYUIは残念ながらメンテナンスされなくなっているようだ*1。 テスタブルJavaScript 作者: Mark Ethan Trostler,牧野聡出版社/メーカー: オライリージャパン発売日: 2013/09/21メディア: 大型本この商品を含むブログ (2件) を見る 後半のツールに関する記述も内容が古いかもしれないが、前半の1,2章は著者の見識が伺える内容だった。 1章は、一般的なソフトウェア開発のアプローチを紹介した上でテストの方法論やツールを紹介していく流れ。 前回のアジャイル開発の流れでBDDについて書いてなかったのでここにメモ。 P6.より ビヘイビア駆動開発（BDD: Behavior-Driven Development）はTDDを元にしており、開発者もそうでない人も共通の言語
ヘッドレス Chrome スタートガイド | Blog | Chrome for Developers
要約 ヘッドレス Chrome は Chrome 59 でリリースされています。これは、ヘッドレス環境で Chrome ブラウザを実行する方法です。つまり、Chrome なしで Chrome を実行することになります。Chromium と Blink レンダリング エンジンが提供する最新のウェブ プラットフォームのすべての機能をコマンドラインにもたらします。 なぜこれが有用なのでしょうか。 ヘッドレス ブラウザは、可視 UI シェルが必要ない自動テストやサーバー環境に最適なツールです。たとえば、実際のウェブページに対してテストを実行したり、その PDF を作成したり、ブラウザが URL をレンダリングする方法を確認したりできます。 ヘッドレスの開始（CLI） ヘッドレス モードを開始する最も簡単な方法は、コマンドラインから Chrome バイナリを開くことです。Chrome 59 以降がイ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - goldbergyoni/javascript-testing-best-practices: 📗🌐 🚢 Comprehensive and exhaustive JavaScript & Node.js testing best practices (August 2025)
1年間単体テストを書き続けた現場から送る Vue Component のテスト / Vue Component Test - Speaker Deck
JavaScriptのE2Eフレームワークを触ってみる
Vueコンポーネントのユニットテスト
