はじめに こんにちは、久しぶりに技術系の記事を書きます、株式会社カンムで機械学習エンジニアをしている fkubota です。 今日はSQLについてです。 弊社に入社してから毎日のようにSQLのクエリを書いてきました。 クエリを書き始めてからもう3年が経とうとしています。 日々クエリを書きながら少しずつ自分のスタイルが出来上がってきているのを日々実感しています。 僕は 正確で 読みやすく 再利用しやすいクエリを 高速に 生み出すための工夫を重ねてきました。 結果的にテスト駆動開発ぽいスタイルが生まれたので今日は紹介してみようと思います。 似たような記事がないので少しドキドキですが温かい気持ちで読んでもらえると嬉しいです。 対象読者 対象読者は、分析のためにクエリを書いている人とします。 プロダクトに乗せるクエリというより、ビジネス的になにか示唆を得たいときにクエリを書く人を想定します。 痛み
目次 目次 はじめに（本記事の見どころなど） テストについて話し合わなくてはならない テストの目的 「うまくいかないかもしれないものは何ですか？」 なぜテストをするのですか？ この場合に限り…… テスト駆動開発 〜テストについて語る前に説明が必要です〜 テストについて話しましょう なぜすべてのテストを自動化しないの？ テストカバレッジは有用な指標ですか？ 「テストをシフトレフトする」とはどういう意味ですか？ いつ、どこでテストすべきですか？ 十分なテストとはどれくらいですか？ おわりに はじめに（本記事の見どころなど） 今回は著者本人の許可をもらった上で、「テストについて話し合わなくてはならない」（原題は「We need to talk about testing」）を翻訳したので紹介します。 dannorth.net 本記事はDaniel Terhorst-North(Dan North
2024/04/17: 更新 内容を更新した記事を書きましたので、よかったらこちらも併せて、ご覧ください。 zenn.dev こんにちは！フロントエンドエキスパートチームの@nus3_です。 kintone のフロントエンド刷新プロジェクト（フロリア）では、品質を保ったまま開発を加速させるためにフロントエンドのテストを積極的に行っています。 今回はそんなフロントエンドのテストの実装例をいくつか紹介します。この記事がフロントエンドのテストを行う上での参考になれば幸いです。 テストに使用する主なパッケージ コンポーネントのテスト 補足: Testing Library の記法をチェックしてくれるeslint-plugin-testing-library カスタムフックのテスト 補足: React v18 では @testing-library/react の renderHook を使う 参考
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） 定義・計画した全テストケー
こんにちは、エンジニアの千吉良（ちぎら）@_naru_jpn です。ここ最近 QA に関して考える機会があり、Systematic Software Testing という本を読んでいたところ、色々と刺激を受けるところがありました。計画書の作成やリスク管理などテストの実施以外の領域についても多く書かれていましたが、まずはミラティブの現状に基づいた改善を行うべきだろうと考えました。今回は特にメトリクスの取得などに関して、GAS（Google Apps Script）を活用してミラティブの業務に応用してみたことについてまとめてみました。 以下では細かいことにも触れているので、3行まとめをおいておきます。 手動テストの進捗を見えるようにしたよ GAS（Google Apps Script）で実装したよ ついでに関連業務を自動化したよ ミラティブにおける QA と解決できそうと感じた課題 ミラティ
まえがき 世間ではテストをしないこと/テストを書かないことを悪とするみたいな文化が定着してきたのか、テストを書かない開発というのが減ってきてると思います。 では「正しくテストを書けているか」「テストを書く文化を生かしているか」というとどうでしょう？ これらの問いに答えられずテストを書くことをゴールにして満足していると、それは宝の持ち腐れならぬテストコードの持ち腐れとなります。 執筆のモチベーション この記事を印刷して札束のごとくビンタするのが目的です。 以下に該当すること”だけ”を考えているような場合はビンタされるかもしれません。（絶対ではないですが危ない可能性があります） うちはテスト書いてるから大丈夫！ちゃんと開発工数とは別に単体テスト工数も見積もってるよ！ ちゃんとホワイトボックス的に書いてカバレッジ担保しているからうちはちゃんとテストしてるよ！ コード修正の都度ちゃんとテストコード
(社内用ドキュメントの公開版) テストのポリシー 前提として、ユニットテストを導入するコストを、限界まで低くすることを目指す。テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し、結果としてテスト不可能な巨大な雪だるまが完成する。こうなるとメンテコストが高いE2Eを大量に書かないといけなくなり、テストの実行時間が膨れ上がっていく。 そうなる前に、ユニットテストを書きやすい環境を維持し、ユニットテストとして問題を切り分けられるような環境を維持する。とにかく書きやすさを重視し、一つのユニットテストを書くオーバーヘッドを限界まで下げる。 最初の一つを早い段階で書く 自分の経験的には、ユニットとテストの最初の一つを書いたらあとは自然とその周辺で増えていく。サンプルがあったら人はコピペする。逆にいうと最初の一つを書かない限り一切書かれない。まず一つ用意するのが大事
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
回路設計・ファーム開発担当のす〜(@ksksue)です。 弊社のBLEモジュールnRF52(Cortex-M4F)のファームウェア開発環境にテストフレームワークUnity導入したところ カンタンな導入でテストコード生産性が飛躍的に上がりました。今回はそのUnityの紹介＆解説です。 IoT開発においてハードウェアとソフトウェアを組合せたテストは品質を担保するために大事な工程ですが、 テスト項目が多くなってくると非常に煩雑になりがちです。Unity導入によってその煩雑さが少なくなりました。 オレオレテストコードをいじりまわす日々 Unity導入前、最初はカンタンなオレオレテスト環境で進めていたのですが、テスト項目数が増えるに従ってその環境自体を場当たり的に改善していくといった作業が発生しました。 正直なことを言うと、改善したいという欲求にあがらえず、必要以上の作業をしていた部分があったと思い
良いテストとはどんなものか，という話をしていて， テストを読めば，そのクラスの使い方や仕様がわかる テストは論文や証明のように上から順番に読めて，上のほうに簡単な一般的な場合，下のほうに難しい，稀に使う場合が書かれている 実装のメソッドと一対一ではなく，ユースケースごとにまとまっている みたいな話をしていた． 機能拡張のさいには，既存のテストを消して，難しい拡張された難しい場合に書き直すのではなくて，既存のシンプルなユースケースも残しつつ，難しい場合を新たに書き足すべき．シンプルな場合を残しておくと，そのクラスを初めて読むときの手助けになる．いきなり難しいケースから始まると，理解が難しくなってしまう．
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、要約、記事で扱う。 [ヨーロッパテストカンファレンス]は、専門家や実践者が一緒に話し、学び、テスト技術を実践するところです。 私たちは、テストをもっと効果的にするために、先進的な新しい方法を詳しく調べ、より強いコミュニティに成長する基本的な方法を十
もうちょっと規約的なものを「JavaでのUT作成基準を整理してみた」にもまとめてみました。 はじめに 去年、ブログの方に「ふつうのユニットテストのための７つのルール」という記事を書いたのですが、思ったより反響がありました。 あの記事で書いたのはあくまで原理・原則で、それを実現するためにはいくつかのテクニックが必要です。 特に、ああいうルールを作って「ユニットテストを書く事」を厳守するようにしても、 適切なテクニックを知らなければメンテが困難だったり、品質に寄与しなかったり、実行性能が悪いゴミが量産される可能性があります。 じゃあ、どうすれば良いかというと「最初からユニットテストが書きやすいように元のコードを設計する」ということです。 そう。まず身に付けるべきは「テストコードの書き方」では無く「テスト対象コード」すなわち「プロダクトコードの書き方」なのです。 また、ここで言ってる「最初から」
はじめに：なぜ Google C++ Testing Frameworkを使うのか¶ Google C++ Testing Framework を上手に活用すれば，より良い C++ のテストを書くことができます． Linux，Windows，そして Mac，あなたが C++ のコードを書いているこれらの環境に関係なく Google Test を利用できます． では，優れたテストを書くにはどうすればよいのでしょうか？Google C++ Testing Framework は，どのように役立つのでしょうか？我々は次のように考えています： テストには， 独立性 と 再現性 が必要です．別のテストの結果に依存して成功したり失敗したりするテスト，をデバッグするのは非常に面倒な作業です．Google C++ Testing Framework は，各テストを異なるオブジェクト上で実行することによって
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
