ShellScriptで自動化を楽にしたい時に知っておいても良いこと | sreake.com | 株式会社スリーシェイク
はじめに こんにちは、皆さん。今日は、シェルスクリプトを使った高度な自動化のベストプラクティスとパターンについて解説します。これらは、ちょっとした知識で実行でき、作業を大幅に効率化できるTipsです。シェルスクリプトは、特にUNIX系システムでの自動化タスクに欠かせないツールです。適切に使用すれば、複雑なタスクを効率的に、そして信頼性高く実行できます。 トイルとは、反復的でマニュアルな作業のことを指します。これには、例えば、手動でのシステムのスケーリングや、エラーのトラブルシューティング、ルーティンなメンテナンス作業などが含まれます。トイルを特定し、それを自動化することで、エンジニアはより創造的なタスクやプロジェクトに焦点を合わせることができます。 トイルを判別する方法としては、以下のような基準が挙げられます： 手作業であること 完全な手作業だけでなく、「あるタスクを自動化するためのスクリ
プログラマ、テスト駆動開発者 和田卓人 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『SQLアンチパターン』（オライリージャパン、2013）監訳。『テスト駆動開発』（オーム社、2017）翻訳。『事業をエンジニアリングする技術者たち』（ラムダノート、2022）編者。テストライブラリ power-assert-js 作者。 講演や執筆などを通じ、日本におけるテスト駆動開発のエバンジェリストとして知られる和田卓人さん。 TDDとは何かを改めて言語化してもらった前回の記事では、「テストを書かずに進むのが合理的といえるときはある。でも、後からテストを書くのって難しいしつらい」とのお話がありました。 テストが書かれないまま
プログラマ、テスト駆動開発者 和田卓人 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『SQLアンチパターン』（オライリージャパン、2013）監訳。『テスト駆動開発』（オーム社、2017）翻訳。『事業をエンジニアリングする技術者たち』（ラムダノート、2022）編者。テストライブラリ power-assert-js 作者。 日本におけるテスト駆動開発（以下、TDD）のエバンジェリストとして知られる和田卓人さん。TDDが世に出て20年あまりが経ち、開発者の間でその名が広がっています。その一方で、和田さんは「TDDの本来の意味を知らなかったり誤解したりしている人たちもかなり増えている」といいます。 今回は、TDDは本質
はじめに Playwright を使うことで比較的簡単に E2E テストを実装することができます。しかし、通常テストコードは実装したら終わりということではなく、継続的にメンテナンス（保守）が必要になります。その際に保守しやすいように実装するため、Playwright の公式ドキュメントに記載されているベストプラクティスの中で参考になりそうな部分を確認しておこうと思います。 テストの独立性を高める 可能な限りテスト間の依存が無いようにして、テストを分離すると良いというプラクティスです。各テストが独立していることで、 １つのテストが失敗しても他のテストに影響しない テストの順序を考慮する必要がない テストをシンプルに保つことができる あたりのメリットがあるかと思います。また、特定の処理（例えば特定の URL に遷移する処理）の繰り返し実装するのを避けるために before and after
Vitest Browser Modeがアツい
Background これまでVitestでコンポーネントのテストを行う時は、jsdom や happy-dom を使ってブラウザ環境を偽装していました。しかし、偽のブラウザ環境を使うことは多くの問題があり、また開発者はテスト以外でどこにも存在しない環境を作り上げるという不毛な作業が必要でした。 この問題を解決するために、Playwright や Cypress などのテストフレームワークは Component Test をサポートしています。しかし、UnitテストでPlaywrightやCypressを使うのは少々Fatであり、Reactのhooksなどのテストをすることができません。 Vitest Browser Modeを使用することで、Vitest上でComponent Testが可能となり、これらの問題を解決できます。 Installation Browser ModeのSetu
Last time, we saw how deleting stuff from a test case can be an easy and fun route to the root cause of a bug. It’s less easy and less fun when the test cases get big. The inner loop of test-case reduction can get old quickly: delete stuff, run the special command, check the output to decide whether to backtrack or proceed. It’s rote, mechanical, and annoyingly error prone. Let’s make the computer
はじめに テスト自動化についての本を書きました。2024年7月30日に発売します。 もともと2021年3月ぐらいから書き始めて、同年12月に書き終わる予定だったのですが、伸びに伸びてこんなことになってしまいました。 幸いなことに興味を持ってくださっている人が多いようなので、ここでは書籍で書ききれなかった、執筆に至るまでの背景（あるいは、いかに自分がE2E自動テストで苦労してきたか）について書いてみたいと思います。 試行錯誤の時期 自分が初めてE2Eテスト自動化に取り組んだのは2018年ごろからで、当時は TestCafe というツールを使っていました。そのころのことは別の記事に書いてあります。 ちょっと引用してみましょう。 イケてるところ コマンド一つでマルチブラウザテスト環境が構築できる これだけで完成です。SeleniumのようにWebDriverのインストールは必要ありません。あとは
Today we are introducing Quartz, a mocking library in Go for testing code that depends on time. By mocking out calls that query or depend on the real time, we can write unit tests that are repeatable, deterministic, and execute as quickly as the CPU allows. This is, in itself, not a new idea. In building Quartz, we took some inspiration from: github.com/benbjohnson/clock Tailscale's tstest.Clock g
はじめに フロントエンド開発において、効率的かつ一貫性のあるモック生成は非常に重要です。本記事では TypeSpec、Orval、Storybook の 3 つのツールを使用して自動生成でモックを実現する方法を紹介します。 TypeSpec は、大規模な API を提供するために Microsoft が開発し、使用している新しい API 記述言語です。 Orval は、OpenAPI 仕様から TypeScript のクライアントコードを生成するツールです。これにより、最新の API 仕様に基づいたクライアントコードを常に保持し、API との通信がスムーズに行えるようになります。 Storybook は、コンポーネントを独立して開発・テストするためのインタラクティブなツールです。コンポーネントの見た目や動作を個別に確認できるため、UI の一貫性を保ちながら効率的に開発を進めることができます
前回の 「プロパティベーステストライブラリを作ってみた」 の続きです。先日ステートフルテストを実装したので、その過程で得られた知見などを紹介したいと思います。 なお、本記事ではステートフルテストの学習を目的としません。ステートフルテストについて学びたい方は 実践プロパティベーステスト をぜひ読んでください。 おことわり この記事の説明は拙作のkiri-checkをベースにしています。kiri-checkのステートフルテストはScalaCheckなどのメジャーなライブラリを参考にしており、他のライブラリと大きな違いは少ないはずです。 kiri-check独自の要素はできるだけ作らないようにしていますが、開発言語(Dart)の違いもあって他のライブラリを完全に模倣するのは難しい面があります。ステートフルテストを試す際は、お使いのライブラリのドキュメントを優先してください。 ステートフルテストと
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Poku
t-wada氏に聞く、テストを書き始めるための「はじめの一歩」 - レバテックラボ（レバテックLAB）
TDDは「開発者テストのTips集」t-wada氏が改めてひも解く“本質” - レバテックラボ（レバテックLAB）
Playwright を使いこなすためのベストプラクティス - Qiita
Automated Test-Case Reduction
「テスト自動化実践ガイド」執筆に至るまで - Qiita
Introducing Quartz: A Deterministic Time Testing Library for Go
TypeSpec、Orval、Storybook を使ってフロントエンドのモック生成を自動化する
プロパティベーステストライブラリを作ってみた（ステートフルテスト編）