Route53のAレコードで所有していないEIP、パブリックIPが設定されていないか「Ghostbuster」を使って把握してみた | DevelopersIO
Route53のAレコードで所有していないEIP、パブリックIPが設定されていないか「Ghostbuster」を使って把握してみた こんにちは、コンサル部＠大阪オフィスのTodaです。 Route53とEC2を利用する中でElastic IP(EIP)やパブリックIPをAレコードに設定して、インスタンス破棄、EIP解放時に消し忘れたというご経験はありませんでしょうか？ 消し忘れたAレコードは悪意のあるユーザにIPを再取得されてサブドメイン乗っ取りにつながる場合がございます。 今回はRoute53のAレコードで、所有していないEIP、パブリックIPが設定されていないかを Ghostbusterというツールを利用して確認してみました。 ■ Github assetnote / ghostbuster https://github.com/assetnote/ghostbuster Route5
Go Style
Documents The Style Guide outlines the foundation of Go style at Google. This document is definitive and is used as the basis for the recommendations in Style Decisions and Best Practices. Style Decisions is a more verbose document that summarizes decisions on specific style points and discusses the reasoning behind the decisions where appropriate. These decisions may occasionally change based on
Unit Test の改善に取り組んでみました | DevelopersIO
はじめに prismatix 事業部で QA エンジニアをしている長友です。 今回は私の所属するチームの方がテスト改善を行ってくださったので、そのお話です。 経緯 今私のいるチームには、私以外に K さんというメンバーの方がおられます。 これまで私の所属する prismatix 事業部で、いろいろなマイクロサービスの開発に携われてきた方です。エンジニアリング力が高く、テストに関する本も出されている方で、私もその方の本を持っています。ですから話すときはよくテストの話題になります。 その方が、これまで開発チームにいた中で作っていたテストコードによるテストのやり方に課題を感じていたということで、今回その改善をすることになりました。 いろいろ試行錯誤をされて、こうしたらいいのではないかというアイデアが出てきたので、それをどうやって開発チームに実践してもらうかをやってみたことをお話します。 なお、私
Will Bun JavaScript Take Node's Crown
Huge thanks to Jarred Sumner for reviewing this post. It wouldn’t have been possible without his help. Bun is a new and ambitious JavaScript toolset and runtime. Early adopters have been reporting that Bun JavaScript is incredibly fast. So fast that it has been touted by some as a Node.js killer. Curious, I decided to check out Bun for myself and benchmark it against the competition. Is it as fast
スモークテストとサニティテストとは何なのか - ソフトウェアの品質を学びまくる
"Sanity check" by foreverdigital is licensed under CC BY-NC-ND 2.0 「サニティテスト」（sanity test）という言葉を聴くことがちょいちょいあったので、意味を捉えておきたいなと思っての記事です。なお、「本当の」「正しい」定義を見つけることが目的ではなく、「こんな風に捉えられていることが多そう」を理解することを意図しています。 また、調べる過程で、自分がかつてまとめた以下のtogetterも見つけてしまったので、「テストタイプなのか、テストレベルなのか、テストフェーズなのか」 という議論も、ここではしません。 togetter.com I/JSTQBでは まずはいつものここからですね。 結論からいうと、サニティテストはスモークテストの類語とされています。 スモークテスト（smoke test） 定義・計画した全テストケー
CloudFrontとS3で作成する静的サイト構成の私的まとめ | DevelopersIO
しばたです。 以前の記事でも触れた様にCloudFrontとS3を使って静的サイトを作る構成に対する理解にあいまいな部分があったので改めてまとめてみました。 特に目新しい話も無く知っている人には当たり前の内容かもしれませんが、まあ、自分自身の理解を整理するために記事にしていきます。 1. S3静的ウェブサイトを使うパターン はじめの構成は「S3静的ウェブサイト」を使ったパターンです。 S3にはバケットの内容を静的ウェブサイトとしてホストできる静的ウェブサイトホスティングの機能があります。 この機能ではHTTPのみ利用可能なためHTTPSを使う場合はCloudFrontと組み合わせる必要があります。 S3静的ウェブサイトを使うにはバケット内のコンテンツを公開する必要があり、S3バケットはパブリックアクセス可能にする必要があります。 また、必ずHTTPのWEBサイトが公開されることになるためユ
コンテキストとセマンティクスを意識してリーダブルなE2Eテストコードを書こう
リーダブルなテストコードについて考えよう ～VeriServe Test Automation Talk No.3～ 2022-07-27 での講演スライドです。
Rustのコードチェックを強力にする3つのツール | κeenのHappy Hacκing Blog
κeenです。 Rustaceanのみなさんは普段書いてるRustのコードを検証するのに cargo check や cargo test などのツールを使っているかと思いますが、それらを強力にするツールの miri 、 MIRAI 、 kani をそれぞれ紹介します。 Rustにはいくつかコードの正しさや行儀のよさを検査する方法がありますね。 cargo check や cargo test 、 あるいはビルドしたバイナリを走らせて検証したり色々手を尽くしているでしょう。 ですがこれらだけだとあらゆる種類のバグを拾いきれる訳ではないのもみなさん承知の通りだと思います。 既存の方法だと手が回らない所があるので他のアプローチでコードを検証してくれるツールがあると嬉しいですよね。 そういったツールを3つ紹介します。 先に注意しておくと、これらのツールはまだ成熟しきってはおらず使いづらい点、使い
単体テストは「2：8の法則」でだいたい品質が担保できる 網羅率・期待値を担保した適切なソリューション
上流品質を担保するために必要な3つのこと 高橋寿一氏（以下、高橋）：Dailyで上流品質を担保するために必要な3つのことです。単体テスト、リファクタリング、要求仕様、ユーザーストーリーのテストケース展開という3つのアクティビティをしっかりやっていただくと、上流でも品質がかなり担保されていくんじゃないのかなと思っています。 単体テストに関しては、基本的には「網羅率を担保してください」みたいなことなので、シンプルです。ただ、まだまだ知られていませんが、0から70パーセントとか80パーセントに持ってくるのは地獄のような作業なので、だいたいみなさん諦めちゃうんです。 でも、テクノロジーが進んでいるのでそこまでやる必要はなくて、「2：8の法則」ですよね。ソフトウェア全体の2割の危ないところだけをテストすれば、だいたい品質は担保されますという。超いい加減な言い方をしましたが、そういうものがあります。
Node.js — Node.js 18 is now available!
We’re excited to announce that Node.js 18 was released today! Highlights include the update of the V8 JavaScript engine to 10.1, global fetch enabled by default, and a core test runner module. Initially, Node.js 18 will replace Node.js 17 as our ‘Current’ release line. As per the release schedule, Node.js 18 will be the 'Current' release for the next 6 months and then promoted to Long-term Support
Makefileの代わりにnpm scripts+zxを使う - 詩と創作・思索のひろば
そこそこの規模があるプロジェクトで実行すべきタスクを定義するとき、初手として Makefile を使いがち。 Pros make は事実上どんな環境にもあることを期待してよい シェルで実行されるコマンドをそのまま書ける タスクの依存関係が明示できる Cons make では positional arguments が使えない 少し複雑なことをしようとすると Makefile 専用の文法を覚える必要がある 現代では、ファイルベースのタスクの依存関係は make が発明されたころほどは必要ではない Docker とか Go とか Webpack がよしなにしてくれることが多い 例: docker compose のラッパー ちょっとしたコマンドのラッパーを書きたいことがある。Makefile を書きはじめたらすべてのエントリポイントを make にしたい。ということで、以下のような Make
Taurus
You run tests more than once It makes sense to automate anything you repeat 10+ times. Taurus improves experience of JMeter, Selenium and others.
dbt (data build tool) を使ってデータをテストする - CUBE SUGAR CONTAINER
ソフトウェアエンジニアリングの世界では、自動化されたテストを使ってコードの振る舞いを検証するのが当たり前になっている。 同じように、データエンジニアリングの世界でも、自動化されたテストを使ってデータの振る舞いを検証するのが望ましい。 データをテストするのに使える OSS のフレームワークも、いくつか存在する。 今回は、その中でも dbt (data build tool) を使ってデータをテストする方法について見ていく。 dbt 自体はデータのテストを主目的としたツールではないものの、テストに関する機能も備えている。 また、dbt には WebUI を備えたマネージドサービスとしての dbt Cloud と、CLI で操作するスタンドアロン版の dbt Core がある。 今回扱うのは後者の dbt Core になる。 使った環境は次のとおり。 $ sw_vers ProductName:
あたらしいテストフレームワークVitestをReactで試してみた | DevelopersIO
単純なテストですがそれでも各項目で想像以上に速度の差があることがわかりました。 開発環境 MacBook Pro (13-inch, M1, 2020) macOS Monterey node v16.13.1 vite v2.7.2 vitest v0.1.20 jest 27.4.7 ts-jest 27.1.3 happy-dom 2.27.0 さいごに まだ開発中ながら一度この速度感に慣れてしまうとJestには戻れなくなってしまいそうです。。Jest互換の記載で書きすすめることができ、移行も容易そうなので正式リリース後にはテストフレームワークとして有力な選択肢となりそうです。Vitest今後の開発が楽しみですね。
jest における MSW の活用事例
MSW を使った jest のテストについて、引数などの検査が面倒という記事を拝見したので、もし同様にアプローチを模索されている方がいらっしゃれば参考に、と思い記事にしました。筆者は普段以下の様に、server.use内にjest.fnを仕込みテストしています。例えば API が2回呼ばれたことを検証する場合、次の様になります。 const server = setupMockServer(...handlers); describe("API call の検証", () => { const mockFn = jest.fn(); beforeEach(() => { server.use( rest.get("/path/to/api", async (req, res, ctx) => { mockFn(); // <- here return res(ctx.json({}));
フロントエンドのテストのモックには msw を使うのが最近の流行りらしい
皆様フロントエンドのテストを書いていらっしゃいますでしょうか？ フロントエンドのテストを書くときには API コールする処理を全てモックする必要があります。外部の API をコールする処理をテストに含めると API サーバーが落ちているなどの外部の要因によってテストが失敗してしまう可能性がありますし、テストを実行するたびに実際に API をコールしてしまうとサーバーに負荷がかかってしまうなど外部に対しても悪影響を与えてしまいます。 さて、従来のモックする手段としては Jest のモックを利用して axios や fetch などのモジュールをモック化する手法がよく使われていたかと思います。 最近のテスト手法として API コールをモックする際に Jest ではなく Mock Service Worker (以下 msw ）を使用する手法が注目されています。実施にどのように使用されているのか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
組織に自動テストを書く文化を根付かせる戦略（2022秋版） / Building Automated Test Culture 2022 Autumn Edition
testingパッケージを使った Webアプリケーションテスト 単体テストからE2Eテストまで / gocon2022spring
GitHub - k1LoW/octocov: octocov is a toolkit for collecting code metrics (code coverage, code to test ratio, test execution time and your own custom metrics).
StorybookのUI Testing Handbookを読んだ
