より信頼できるクエリを書くために、SQLでもテストを書く - ハヤオキスルフクロウ
はじめに こんにちは、久しぶりに技術系の記事を書きます、株式会社カンムで機械学習エンジニアをしている fkubota です。 今日はSQLについてです。 弊社に入社してから毎日のようにSQLのクエリを書いてきました。 クエリを書き始めてからもう3年が経とうとしています。 日々クエリを書きながら少しずつ自分のスタイルが出来上がってきているのを日々実感しています。 僕は 正確で 読みやすく 再利用しやすいクエリを 高速に 生み出すための工夫を重ねてきました。 結果的にテスト駆動開発ぽいスタイルが生まれたので今日は紹介してみようと思います。 似たような記事がないので少しドキドキですが温かい気持ちで読んでもらえると嬉しいです。 対象読者 対象読者は、分析のためにクエリを書いている人とします。 プロダクトに乗せるクエリというより、ビジネス的になにか示唆を得たいときにクエリを書く人を想定します。 痛み
【翻訳記事】BDDの考案者が執筆した記事「テストについて話し合わなくてはならない」を翻訳しました！ - ブロッコリーのブログ
目次 目次 はじめに（本記事の見どころなど） テストについて話し合わなくてはならない テストの目的 「うまくいかないかもしれないものは何ですか？」 なぜテストをするのですか？ この場合に限り…… テスト駆動開発 〜テストについて語る前に説明が必要です〜 テストについて話しましょう なぜすべてのテストを自動化しないの？ テストカバレッジは有用な指標ですか？ 「テストをシフトレフトする」とはどういう意味ですか？ いつ、どこでテストすべきですか？ 十分なテストとはどれくらいですか？ おわりに はじめに（本記事の見どころなど） 今回は著者本人の許可をもらった上で、「テストについて話し合わなくてはならない」（原題は「We need to talk about testing」）を翻訳したので紹介します。 dannorth.net 本記事はDaniel Terhorst-North(Dan North
実装例から見る React のテストの書き方 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは！フロントエンドエキスパートチームの@nus3_です。 kintone のフロントエンド刷新プロジェクト（フロリア）では、品質を保ったまま開発を加速させるためにフロントエンドのテストを積極的に行っています。 今回はそんなフロントエンドのテストの実装例をいくつか紹介します。この記事がフロントエンドのテストを行う上での参考になれば幸いです。 テストに使用する主なパッケージ コンポーネントのテスト 補足: Testing Library の記法をチェックしてくれるeslint-plugin-testing-library カスタムフックのテスト 補足: React v18 では @testing-library/react の renderHook を使う 参考リンク 色々なテスト事例 setTimeout を使うコンポーネントのテスト 補足: Storybook の story を使
ReactでTesting Library/Jestを使ってテストを学ぼう | アールエフェクト
Reactを学び始めてコードを書けるようになったので記述したコードのテストを実行してみたいという人を対象にReactでのテスト方法について説明を行っています。 Testing Libraryとは？Jestとは？ Reactでのテストを行う前にテストに利用するライブラリについて説明を行っておきます。 ReactアプリケーションのテストはTesting Library、Jestを利用して行うことができます。Testing LibararyもJestもReactに限定されたライブラリではありません。VueやSvelteを含めた他のフレームワークでも利用することができます。Testing LibararyではReact用のReact Testing Libraryが提供されておりcreate-react-appを利用してReactプロジェクトを作成すると自動でインストールされます。Tesing L
スモークテストとサニティテストとは何なのか - ソフトウェアの品質を学びまくる
"Sanity check" by foreverdigital is licensed under CC BY-NC-ND 2.0 「サニティテスト」（sanity test）という言葉を聴くことがちょいちょいあったので、意味を捉えておきたいなと思っての記事です。なお、「本当の」「正しい」定義を見つけることが目的ではなく、「こんな風に捉えられていることが多そう」を理解することを意図しています。 また、調べる過程で、自分がかつてまとめた以下のtogetterも見つけてしまったので、「テストタイプなのか、テストレベルなのか、テストフェーズなのか」 という議論も、ここではしません。 togetter.com I/JSTQBでは まずはいつものここからですね。 結論からいうと、サニティテストはスモークテストの類語とされています。 スモークテスト（smoke test） 定義・計画した全テストケー
テスト工程の可視化や自動化に向けた取り組みのご紹介 - Mirrativ Tech Blog
こんにちは、エンジニアの千吉良（ちぎら）@_naru_jpn です。ここ最近 QA に関して考える機会があり、Systematic Software Testing という本を読んでいたところ、色々と刺激を受けるところがありました。計画書の作成やリスク管理などテストの実施以外の領域についても多く書かれていましたが、まずはミラティブの現状に基づいた改善を行うべきだろうと考えました。今回は特にメトリクスの取得などに関して、GAS（Google Apps Script）を活用してミラティブの業務に応用してみたことについてまとめてみました。 以下では細かいことにも触れているので、3行まとめをおいておきます。 手動テストの進捗を見えるようにしたよ GAS（Google Apps Script）で実装したよ ついでに関連業務を自動化したよ ミラティブにおける QA と解決できそうと感じた課題 ミラティ
テストコードをただ書くだけで満足している人々をこの記事でビンタしたい - Qiita
まえがき 世間ではテストをしないこと/テストを書かないことを悪とするみたいな文化が定着してきたのか、テストを書かない開発というのが減ってきてると思います。 では「正しくテストを書けているか」「テストを書く文化を生かしているか」というとどうでしょう？ これらの問いに答えられずテストを書くことをゴールにして満足していると、それは宝の持ち腐れならぬテストコードの持ち腐れとなります。 執筆のモチベーション この記事を印刷して札束のごとくビンタするのが目的です。 以下に該当すること”だけ”を考えているような場合はビンタされるかもしれません。（絶対ではないですが危ない可能性があります） うちはテスト書いてるから大丈夫！ちゃんと開発工数とは別に単体テスト工数も見積もってるよ！ ちゃんとホワイトボックス的に書いてカバレッジ担保しているからうちはちゃんとテストしてるよ！ コード修正の都度ちゃんとテストコード
(自分の) JavaScript のユニットテストの書き方
(社内用ドキュメントの公開版) テストのポリシー 前提として、ユニットテストを導入するコストを、限界まで低くすることを目指す。テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し、結果としてテスト不可能な巨大な雪だるまが完成する。こうなるとメンテコストが高いE2Eを大量に書かないといけなくなり、テストの実行時間が膨れ上がっていく。 そうなる前に、ユニットテストを書きやすい環境を維持し、ユニットテストとして問題を切り分けられるような環境を維持する。とにかく書きやすさを重視し、一つのユニットテストを書くオーバーヘッドを限界まで下げる。 最初の一つを早い段階で書く 自分の経験的には、ユニットとテストの最初の一つを書いたらあとは自然とその周辺で増えていく。サンプルがあったら人はコピペする。逆にいうと最初の一つを書かない限り一切書かれない。まず一つ用意するのが大事
現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
組込みCテストフレームワークUnityを導入してテストコード生産性をUp - フォトシンス エンジニアブログ
回路設計・ファーム開発担当のす〜(@ksksue)です。 弊社のBLEモジュールnRF52(Cortex-M4F)のファームウェア開発環境にテストフレームワークUnity導入したところ カンタンな導入でテストコード生産性が飛躍的に上がりました。今回はそのUnityの紹介＆解説です。 IoT開発においてハードウェアとソフトウェアを組合せたテストは品質を担保するために大事な工程ですが、 テスト項目が多くなってくると非常に煩雑になりがちです。Unity導入によってその煩雑さが少なくなりました。 オレオレテストコードをいじりまわす日々 Unity導入前、最初はカンタンなオレオレテスト環境で進めていたのですが、テスト項目数が増えるに従ってその環境自体を場当たり的に改善していくといった作業が発生しました。 正直なことを言うと、改善したいという欲求にあがらえず、必要以上の作業をしていた部分があったと思い
良いテスト - hitode909の日記
良いテストとはどんなものか，という話をしていて， テストを読めば，そのクラスの使い方や仕様がわかる テストは論文や証明のように上から順番に読めて，上のほうに簡単な一般的な場合，下のほうに難しい，稀に使う場合が書かれている 実装のメソッドと一対一ではなく，ユースケースごとにまとまっている みたいな話をしていた． 機能拡張のさいには，既存のテストを消して，難しい拡張された難しい場合に書き直すのではなくて，既存のシンプルなユースケースも残しつつ，難しい場合を新たに書き足すべき．シンプルな場合を残しておくと，そのクラスを初めて読むときの手助けになる．いきなり難しいケースから始まると，理解が難しくなってしまう．
ChromeのヘッドレスモードをMacOSXで試してみた - Qiita
マストドンで盛り上がる最中、 こっそり一部で盛り上がってたChromeのヘッドレスモード MacOSXで少し試してみたいと思います。 開発中の機能ということで、仕様の変更もあると思いますが、2017/4/16段階ではちゃんと以下のやり方で動作してます:) 準備 Google Chrome Canaryをインストール 開発段階にある機能がのってるchromeです。ささっと入れちゃいます。 nodejsインストール(v6.3以上) ちなみに今回試したのはv7.9.0 シェルにCanaryバイナリへのエイリアスを作成します(僕は.zshrcに追加しました/bashの人は.bash_profileかな) alias chrome-c='/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary'
テストでHTMLの要素をどうやって辿るか - hitode909の日記
HTMLでUIを作っていて，has_moreがfalseならなにも表示しない，has_moreがtrueなら「もっと読む」ボタンを出すとする． has_moreにtrueを与えたときには要素が出て，has_moreがfalseを与えたときは要素が出てない，ということをテストしたい． このときにやりかたはいろいろ考えられて， ソースを正規表現で評価して/<button/iがあるか調べる HTMLとしてパースしてないので偶然文字列が一致する可能性がある getElementsByTagName的なものでbuttonタグを探す buttonタグが複数出たときなど，変更に弱い button.see-moreみたいにCSSセレクタで要素を探す デザインの都合でsee-moreクラスを消してしまうとテストが落ちる button.test-see-moreみたいにクラスを付与して，テスト用のセレクタはt
よいユニットテストを書くには
テストを小さくする。適切なツールを使う。プログラマとテストがペアになる。これらは、よいユニットテストを書くための、Adrian Bolboaca氏からの提案だ。 ユニットテストは、プログラミングとテストが混ざり合ったものだ。プログラマは、テスタと共に作業することで、お互いに学び合い、視野を広げることができる。 Adrian Bolboaca氏は、Mozaic Worksの組織と技術に関するコーチであり、ヨーロッパテストカンファレンス 2017において、様々なタイプの自動テストについて話す予定だ。 InfoQは、このカンファレンスについて、Q&A、要約、記事で扱う。 [ヨーロッパテストカンファレンス]は、専門家や実践者が一緒に話し、学び、テスト技術を実践するところです。 私たちは、テストをもっと効果的にするために、先進的な新しい方法を詳しく調べ、より強いコミュニティに成長する基本的な方法を十
これだけは覚えたい、ユニットテストを書くための４つのデザイン - Qiita
もうちょっと規約的なものを「JavaでのUT作成基準を整理してみた」にもまとめてみました。 はじめに 去年、ブログの方に「ふつうのユニットテストのための７つのルール」という記事を書いたのですが、思ったより反響がありました。 あの記事で書いたのはあくまで原理・原則で、それを実現するためにはいくつかのテクニックが必要です。 特に、ああいうルールを作って「ユニットテストを書く事」を厳守するようにしても、 適切なテクニックを知らなければメンテが困難だったり、品質に寄与しなかったり、実行性能が悪いゴミが量産される可能性があります。 じゃあ、どうすれば良いかというと「最初からユニットテストが書きやすいように元のコードを設計する」ということです。 そう。まず身に付けるべきは「テストコードの書き方」では無く「テスト対象コード」すなわち「プロダクトコードの書き方」なのです。 また、ここで言ってる「最初から」
入門ガイド — Google Test ドキュメント日本語訳
はじめに：なぜ Google C++ Testing Frameworkを使うのか¶ Google C++ Testing Framework を上手に活用すれば，より良い C++ のテストを書くことができます． Linux，Windows，そして Mac，あなたが C++ のコードを書いているこれらの環境に関係なく Google Test を利用できます． では，優れたテストを書くにはどうすればよいのでしょうか？Google C++ Testing Framework は，どのように役立つのでしょうか？我々は次のように考えています： テストには， 独立性 と 再現性 が必要です．別のテストの結果に依存して成功したり失敗したりするテスト，をデバッグするのは非常に面倒な作業です．Google C++ Testing Framework は，各テストを異なるオブジェクト上で実行することによって
SSDに2PB(200万ギガバイト)書き込みまくると性能はどれくらい落ちるのか？
SSD主要6モデルに特別なプログラムを使って尋常ではない量のデータを書き込みまくって再起不能まで追い込む耐久比較実験を、The Tech Reportが絶賛敢行中です。実験ではすでにIntel「335」、Corsair「Neutron GTX」、Samsung「840」を葬り去ってきました。最後まで残ったSamsung「840 Pro」とKingston「HyperX 3K」は2PB(200万GB)の大台を突破してもなお健在。2PBという超大容量の書き込みに耐えたと言うこと自体が、驚異的なのですが、2PBの書き込みによってSSDのパフォーマンス(速度)はどのように悪化するのかについて興味深いデータが明らかになりました。 The SSD Endurance Experiment: Two freaking petabytes - The Tech Report - Page 1 http:/
なぜ Square の社食は朝と昼が有料で、夜は無料になったのですか？ - Knoh (ノウ) | The Knowledge Hub
私たちは、自分たちの製品をテストするために朝食と昼食にお金を払っています。スタッフは全員、ランチ時に交代でレジ係を努めることで、最新のベータ版の Square Register をテストします。ランチの代金を支払う側のスタッフは、最新の Square Wallet のビルドを利用します。私たちは全員、まだリリースされていない製品のベータテスターなんです。 また、Square Register を使い、朝食と昼食の代金を Square Wallet から受け取ることで、我々はビジネスオーナーと顧客のエクスペリエンスを会社のコーヒーバーで再現しています。ほぼ毎日、こういうテストの場には新しいベータ版の製品が用意されています。これによって、私たちは、即座にフィードバックを受けることができ、毎日 500 件以上ものトランザクションのテストが行えています。 製品をリリースするには、ビルドが 10,0
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブックマーク - GitHubがダウン 「データストレージシステムに障害」 - ITmedia NEWS
Google Test の始め方 - Qiita
