こんにちは。エンジニアの原です。 先日、「テスト駆動開発」の翻訳者として知られるt_wadaさんこと和田卓人さんをお招きして、テスト駆動開発ワークショップの第1回目をオンラインで開催しました。 今回はその様子をお届けします。 本日は Classi 株式会社様にお招きいただき、1日コースの TDD ワークショップをオンラインで行いました。参加される皆様のレベルが高めなので反転学習の要素を取り入れた研修を設計しましたが、予想以上に効果があったと手応えを感じています。ご参加くださいました皆様、ありがとうございました！— Takuto Wada (@t_wada) December 15, 2020 きっかけ Classiでは毎年外部講師をお招きして勉強会を行っています。 新卒研修を行う中で、「テストコードを実装する際の勘所」をどう伝えようかという話があり、第一人者のt_wadaさんをお呼びして研
はじめに 読書会をやってみました オープンロジのエンジニアのrikuto（@riku929hr）です。 社内で「単体テストの考え方・使い方」というテストに関する有名な本の読書会を実施し、1回1時間、15回の開催を経て読み切りました。 原著は「Unit Testing Principles, Practices, and Patterns」で、Oreilly Learning Platformでも読むことができます。 400ページにもわたる本で、読み切るのには大変な手応えがありました。 たぶん読書会のようなものを開催しない限り、僕自身読みきれなかったかもしれません。 しかし読んでみると、著者が主張しているのはごくシンプルなことでした。 この記事のタイトル、ちょっと嘘ついてます タイトルには、「主張するたった一つのこと」としていますが、細かく言えば1つではありません。 この本が主張することはそ
TDD in a React frontend
2021-01-19 React, tddTDD in a React frontendNowadays, only a few professional developers are left that seriously doubt the value of test-driven-development and test-driven-design (tdd). But the reality of many codebases I have seen is that tdd is often limited to the backend, where the "business logic" lives. Part of this is due to a stigma that frontend development is not "real software developme
privateメソッドをテストしたい - 日々常々
と思うのは、とてもいいこと。 前置き もし行いたいテストが外的振る舞いを示すものであれば（少なくともテストにより観測できる見通しがなければ「テストしたい」とは思わないだろうから、何かしら外から観測可能なものではある可能性は高い）、それがprivateに閉じていていいものではないと言う気づきのきっかけになる。 と言うのは教科書的回答だけど、外には見せたくないけれど複雑なロジックを包含していて、入念かつ局所的にテストしたいと思うこともある。 この動機はすごく自然。きっとそこはテストしなかったらバグってるし。テストしてもバグが見つからないと言うのもよくあるんだけど。 この手のがどうあるのがいいのかはチーム体制も含めたプロダクトによると思っている。 綺麗な考え方は、独立したコンポーネントとして関心ごとや複雑性を閉じ込め、テストしたいと思った内容にもっと高い格を与える。「格」なんて表現は他で使ったこ
test.each([ {a: 1, b: 1, expected: 2}, {a: 30, b: 5, expected: 25}, ])('.sum($a, $b)', ({ a, b, expected }) => { expect(sub(a, b).toBe(expected); }); テーブル駆動テストは Go 言語を使った開発で良く使われるスタイルです。Go 言語の GitHub リポジトリの Wiki にはテーブル駆動テストに関するページがあるので、興味がある人はそちらを読んでみてください。 テーブル駆動テストを使った QA エンジニアとソフトウェアエンジニアの連携 テストがなくリファクタリングが困難なフロントエンド 症状検索エンジン ユビー には、ユビーのビジネスにとって重要な、とあるページがあります。そのページではフロントエンドからロギングサービスに対してたくさんのロ
本連載の主なテーマは、信頼できる実行結果にできるだけ短い時間でたどり着く自動テスト群の構築です。連載の区切りとして、なぜ自動テストを書いてメンテナンスしていくのか、そしてそれに立ちはだかる「脆いテスト」（fragile test）について整理します。 自動テストを書く動機 自動テストを書く動機には、不具合混入を防止する、問題箇所の絞り込みを容易にする、動く仕様書やサンプルになるなどいろいろありますが、最大の動機は、変化を抱擁し、ソフトウェアの成長を持続可能なものにすることだと筆者は考えています。 ソフトウェアを取り巻く世界は変わりました。ソフトウェアは世界を飲み込み、事業と一体化しました。事業を取り巻く市場もエンドユーザーのニーズも刻々と変化する時代においては、より速く、より安全に変化する力が求められます。コードを変更しなければ動き続けることが期待できる時代ではもうなく、決められたものを
PHP Conference Japan 2021での発表資料です https://fortee.jp/phpcon-2021/proposal/3ed8a69b-8618-4644-9a8c-655505078743
Lessons from Writing a Compiler
The prototypical compilers textbook is: 600 pages on parsing theory. Three pages of type-checking a first-order type system like C. Zero pages on storing and checking the correctness of declarations (the “symbol table”). Zero pages on the compilation model, and efficiently implementing separate compilation. 450 pages on optimization and code generation. The standard academic literature is most use
Announcing Vitest 3.0
Vitest 3.0 is out! January 17, 2025 We released Vitest 2 half a year ago. We have seen huge adoption, from 4,8M to 7,7M weekly npm downloads. Our ecosystem is growing rapidly too. Among others, Storybook new testing capabilities powered by our vscode extension and browser mode and Matt Pocock is building Evalite, a tool for evaluating AI-powered apps, on top of Vitest. The next Vitest major is he
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).
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
フロントエンド:単体テストの観点
対象読者 Jest や Testing Library のテストの書き方は理解しているが、何をテストすべきかわからないという方。 動機 近年、フロントエンドでもテストを書くことが重要視されるようになってきました。 テスト導入する際、共通で利用するコンポーネントや関数などをテストする記事は多いですが、何をテストすべきかについての記事が見当たらなかったため、私が意識してるテスト観点を執筆しようと思いました。 まず初めに各種テストの説明 単体テスト 関数やメソッドなどの最小単位の部分を個別にテストする手法のこと。 利用ツール例 Jest React-Testing-Library 結合テスト 複数のコンポーネントが、互いにうまく動作していることをテストする手法のこと。 利用ツール例 Jest React-Testing-Library End to End （E2E）テスト ユーザーが実際にシス
Puppeteer と Coverage の話
アドカレの 1 日目も Puppeteer の話を書いてたのだけど、別にその続きとかではまったくなくて、少し前に Puppeteer のカバレッジ関連でドハマリしたのでそれを書こうと思う。 背景他のところで散々書いてきているので、軽く触れる程度にしておくが、 https://github.com/reg-viz/storycap というツールの開発・メンテをしている。Puppeteer で Storybook をクローリングして各 Story を PNG 画像にする、ただそれだけの CLI だ。 このツールは画像ベースの回帰テストを自動化する目的で作られていて、日々の業務でも reg-suit や reg-cli などのツールと組み合わせて使っており、僕自身も前職の頃から世話になっている CLI だ。 自動テストの一環として Storycap を使っている関係上、Storybook をコン
GitHub - plantain-00/type-coverage: A CLI tool to check type coverage for typescript code
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
概要 Storybook6.4からデフォルトでCSF3の書き方が使えるようになったので、自分なりに調べたことをまとめてみました。TypeScript + Reactで説明します。 公式の記事はこちら この記事の内容は以下のとおりです。 CSF2からCSF3の変更点 CSFの既知の問題と公式の対応状況 インタラクティブストーリーの書き方 CSF3で書いたストーリーをユニットテストに応用する方法 この記事の説明で使うコンポーネント 名前を入力してSubmitボタンを押すと、ボタンを押した時の入力テキストを下に表示するコンポーネントです。 import { VFC, useState } from 'react' export type Props = { title: string } const SimpleFrom: VFC<Props> = ({ title }) => { const
Code Coverage: More Than a Metric. Codecov is the all-in-one code coverage and quality solution for any test suite — giving developers actionable insights to deploy reliable code with confidence. Trusted by over 29,000 organizations. Try Codecov for Free Get Demo
【感想】『ちょうぜつソフトウェア設計入門 ――PHPで理解するオブジェクト指向の活用』：圧倒的表紙詐欺からのちょうぜつ深い設計入門 - Rのつく財団入り口
#ちょうぜつ本 を読み進める前に言っておく! （AA略 2022/12刊行、エンジニア界隈でも話題になった本。著者の田中ひさてるさんがSoftware Design誌に連載した記事＋アドベントカレンダー掲載の話＋カラーページに同雑誌のちょうぜつエンジニアめもりーちゃんの連載分も掲載した、ソフトウェアの設計を深く深く追求した本となっています。 表紙のキャラはちょうぜつエンジニアめもりーちゃん(銀髪?ロング姫カットの右側の子)とゆにっとさん(緑髪ショートにマリンルックの左の子)をメインに、ちょうぜつ技術書らしからぬ表紙。 最初は「オッコンピュータ書籍に時々ある萌え絵の表紙でオタク系エンジニャ〜を釣るタイプの本でゴザルな。拙者こういう本もイケるクチでござるよデュフ〜」的なちょうぜつ軽い感覚で読み始めたのですが... #ちょうぜつ本 を読み進める前に言っておく! （AA略 ちょうぜつエンジニアメモ
GIHOZ | HQW!
“今すぐ使える”テスト技法ツールGIHOZはベリサーブID取得のみで、すぐに利用が可能です。高品質なテストを効率よく作成するために、熟練のテストエンジニアが利用しているさまざまなテスト技法を手軽に体感してください。 1手軽にテストケースを 作成・利用 2目的に応じて テスト技法を選択 3ソフトウェア開発の 効率化に貢献 直感的な操作でさまざまなテスト技法を利用可能GIHOZは、表計算ソフトなどの汎用的なツールと異なり、テスト技法ごとに最適なユーザーインターフェースをご提供します。 直感的な操作でテスト技法を正しく利用でき、素早くテストケースを作成できます。
単体テストの考え方/使い方 まとめ
著者は古典学派のスタイルを好んでいて、本書では古典学派の定義を採用している テスト対象の焦点をクラスに当てるのは間違っていて、1単位の振る舞いに焦点を当てなければいけない。 また、ロンドン学派のスタイルだと単体テストがテスト対象の内部的なコードと密接に結びつく傾向があるため、賛同できない。 3章 単体テストの構造的解析 AAAパターンという単体テストの構造を用いることで、全てのテストケースに対して簡潔で統一された構造を持たせることができる。また、この構造に慣れることで読みやすさが向上し、保守コストを下げることにつながる。 準備フェーズ(Arrange)フェーズ...ケースの事前条件を満たすように、テスト対象システムとその依存の状態を設定するフェーズ 実行(Act)フェーズ...テスト対象の振る舞いを実行するフェーズ 確認(Assert)フェーズ...実行した結果が想定した結果であることを確
ホワイトボックステストにおけるカバレッジとテストケース(C0, C1, C2, CDC, MC/DC, MCC) - ろぐれこーど
ホワイトボックステストでよく用いられる網羅率(coverage)について、違いがよくわかっていなかったためまとめてみました。間違いあれば更新します。 網羅率(coverage, カバレッジ)とは カバレッジ基準 命令網羅 : statement coverage (C0) 判定条件網羅 : decision coverage(C1) 条件網羅 : condition coverage(C2) 判定条件/条件網羅 : condition / decision coverage(DC/CC, CDC) 改良条件判定網羅 : modified condition/decision coverage(MC/DC) 複合条件網羅 : multiple condition coverage(MCC) 経路組み合わせ網羅 : path coverage まとめ 参考 網羅率(coverage, カバレッ
Poetryでプライベートリポジトリからパッケージをインストールする必要がありいろいろ調べてみたのでそのメモ。あとAWS CodeArtifactも試してみたので。 はじめに まず、pipもpoetryも基本的には依存関係の解決、つまりパッケージのインストールにはPyPIというリポジトリを参照しているのはご存知だと思うが、したがって通常自作のパッケージを公開するにはこのPyPIへの公開が必要となる。 PyPIで公開するにはPoetryではpoetry buildで配布用パッケージを作成してpoetry publishで可能。 だが、何らかの理由でパブリックには公開したくない、でもいくつかのプロジェクトから利用したいって場合があると思います。 そんなときに一番簡単なのはインストールしたいプロジェクトのリポジトリに同梱してしまうことですが複数のプロジェクトから利用する場合はそれもどうかと思いま
カバレッジとは、検査網羅率(テストカバレージ) のことを指し、どれだけテストしたかの指標を表します。 ソフトウェアテストにおいて、カバレッジ（網羅率）を測定／分析することは、ソフトウェアの品質向上に非常に大きな意味があります。 コードのカバレッジを測定し、テストが実施されていないコード（通らないプログラム）を確認することにより、テストの妥当性を向上させることができます。 一般的には、単体テストでコードのカバレッジを測定し、テストの品質を測ります。 C++testなどの静的解析ツールも出ています。 その指標の中に、網羅率ごとのC0/C1/C2カバレッジがあります。 C0：命令網羅（ステートメント・カバレッジ） C1：分岐網羅（ブランチ・カバレッジ） C2：条件網羅（コンディション・カバレッジ） 文章にすると上記のとおりなのですが、毎回忘れてしまいがちなので、コードと照らし合わせてまとめておき
こんにちは。EC事業部CREチームの rotelstift といいます。 私は主にカラーミーショップへのお客様からの技術的なお問い合わせに答え、希望された機能追加や発覚したバグの修正などを担当しています。 プログラマという職業に就いたのはペパボが1社目で35歳からというスロースターターですが、ペパボという会社はいるだけで成長できる会社だということを実感しています。 今回は、職業プログラマになる前はほとんど書いたことの無かったテストコードについて学んだこととして、読みやすさを劇的に改善する AAA (arrange, act, assert) と呼ばれる指針の解説をしたいと思います。 なお、この記事では RSpec を題材にした単体テストを扱います。 読みにくいテストコードの例 まず最初に、以下のテストコードを見てみましょう。なんか読みにくいと感じます。これが読みにくいのは AAA の各要素
いつも ng new 一発でテスト環境まで準備済みだが、ふとユニットテスト環境を作るのにどういうパッケージとどういう設定が必要かきになったので試してみた記録 テスト環境がない状態で Angular アプリケーションを用意 ng new のオプションにめちゃくちゃ都合のいい minimal があったのでこれを使ってアプリケーションを用意 $ npx @angular/cli new ng-sample --minimal ? Would you like to add Angular routing? No ? Which stylesheet format would you like to use? SCSS [ https://sass-lang.com/documentation/syntax#scss ] CREATE ng-sample/README.md (1038 bytes
GitHub Actionsでカバレッジを可視化する
モチベーション 今携わっているプロダクトは、DDD+Clean Architectureなマイクロサービスとして構築しています。 自身の担当業務としてはレセプト関係になります。業務の特性上、複雑なビジネスルールをきっちりかっちり作らないといけないのでテストはかなり重点的に書いています。 ビジネスルール、ユースケースといったレイヤー化されたクラスにそれぞれテストを書いていくわけですが、ユースケースが依存しているビジネスルールが一つの場合など、いちいちユースケース単体でテストを書くのか？ということもあり、ケースによりますがテスト粒度を上げるという判断もしてたりします。 テストコーディング時に依存性を排除する為にモックを大量に使いますが、上記のような判断があったり、なかったりするとテストのカバー範囲の認識齟齬というものが出てきて最終的にカバレッジが漏れる事案が発生します。 またPRレビュー時にテ
jest のコマンドラインランナーは多くの便利なオプションを持っています。 jest --help を実行することで使用可能な全てのオプションを見ることができます。 以下に示すオプションの多くは任意のテストを実行する際に利用できます。 Jest の各設定オプションは CLI 経由で指定できます。 以下に簡単な概要を示します。 コマンドラインから実行する 全てのテストを実行する (既定値):
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
はじめに この記事は、アルサーガパートナーズ アドベントカレンダー2023、番外編の記事です。 「25日間のリレー」を成功に導いた素敵な記事たちがカレンダーに集まっていますので、よろしければ下記のリンクからご覧ください！ この記事について 実務における最初の壁: DI 未経験からエンジニアとして実務に携わるようになると、誰しも「独学でやっていた時とは違うな」と感じることがたくさんあると思います。 私のサーバーサイドエンジニアとしてのキャリアはLaravelによる開発からスタートしたのですが、そんな私にとっての最初の「自己学習と実務の違い」の1つは、DI(Dependency Injection, 依存性注入) の概念が実装に利用されていること、でした。 すでに実装されている先輩方のコードを読めば「どう書けばいいか」はある程度すぐに把握できたものの、概念の理解を進めようとしても抽象的で難解な
この記事では、マネージド コード用の Microsoft 単体テスト フレームワークと Visual Studio テスト エクスプローラーを使用して一連の単体テストを作成、実行、およびカスタマイズする手順について説明します。 開発中の C# プロジェクトで作業を開始し、そのコードを実行するテストを作成し、テストを実行し、結果を調べます。 次に、プロジェクト コードを変更し、テストを再実行します。 これらの手順を実行する前に、これらのタスクの概念の概要を確認したい場合は、「単体テストの基本」を参照してください。 既存のコードからテストを自動的に生成する場合は、「コードから単体テスト メソッド スタブを作成する」を参照してください。 テストするプロジェクトを作成する Visual Studio を開きます。 スタート ウィンドウで、 [新しいプロジェクトの作成] を選択します。 .NET 用
Comparing xUnit.net to other frameworks Table of Contents Attributes Assertions Attributes NUnit 3.x MSTest 15.x xUnit.net v2 Comments
In this post, we’ll make a deep dive into the DRY and DAMP principles and will talk about the false dichotomy around them. The DRY principle stands for "Don’t Repeat Yourself" and requires that any piece of domain knowledge has a single representation in your code base. In other words, in requires that you don’t duplicate the domain knowledge. The DAMP principle stands for "Descriptive and Meaning
xUnitを使っている。 Visual Studio 2019で突然UnitTestが実行できない状況に。 原因と対処を備忘録としてノートする。 環境 OS Windows 10 Pro (20H2) IDEとFramework Visual Studio 2019 (16.8.4) .NET Core 3.1 UnitTestライブラリ xunit v2.4.1 xunit.runner.visualstudio v2.4.3 Microsoft.NET.Test.Sdk v16.8.3 事象 Visual Studio上でUnit Testを実行するものの、テストがRunしない。 ステータスバー以下メッセージが表示される。 「予期しないエラーが検出されました。詳細については、テスト出力ペインをご確認ください。」 出力 → 出力元（S）: → テストを開くと下記のログが出力されていた。
Python3 で 公式のunittestを利用してテストを行い、 コードカバレッジをエディタ上に表示するまでの方法を記録した手記です。 1. 目指すゴール 以下のような形で、Pythonのコード上にテストカバレッジが表示できるところまでをゴールとします。その他の周辺知識については、なるべく割愛します。 読者のレベル想定 Pythonで動作するプログラムが作れる（.pyファイルを作成できる、著者もこのレベルなので早くレベル上げていきたいです。） Pythonの実行ができる人 環境構築や説明をこのページ内にある環境構築方法やコマンドを、自身で補完しながら作業ができる方 テストカバレッジという言葉に説明が要らない方 筆者の環境 OS: Mac OS 10.13.6（17G7024） エディタ: VSCode ・汎用的なプラグインを入れる作業を実施済み。特に日本語プラグインを著者の環境で入れちゃ
-----------|----------|----------|----------|----------|-------------------| File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s | -----------|----------|----------|----------|----------|-------------------| All files | 85.71 | 62.5 | 100 | 85.71 | | tester.ts | 85.71 | 62.5 | 100 | 85.71 | 62 | -----------|----------|----------|----------|----------|-------------------| が、このカバレッジレポー
この記事はBASEアドベントカレンダー2024の18日目の記事です。18日目は shota.imazeki さんの記事（INFORMATION_SCHEMAを用いたBigQueryデータ監視 - BASEプロダクトチームブログ）も公開されていますので、ぜひご一緒に読んでみてください。 はじめに こんにちは、はじめまして。BASE の Feature Dev1 Group でバックエンドエンジニアをしている @meihei です。 2024年6月に入社してから半年が経ち、この間に多くの経験を積ませていただきました。 この記事では、私の日常の開発業務、特にローカル環境で PHPUnit を自動的・継続的に実行している方法についてお話しします。 息を吸うように PHPUnit を実行する さて、具体的に何をしているかと言うと、PhpStorm で PHPUnit 実行後の「Rerun Autom
WinAppDriverを使って、WindowsアプリのUIテストを自動化する。 環境構築手順や各操作の記述方法を以下にまとめる。 環境 Windows 10（開発者モード有効） Visual Studio 2019 インストール WinAppDriverのインストーラをダウンロードする。 https://github.com/microsoft/WinAppDriver/releases WinAppDriverをインストールする。 Windows 10の開発者モードを有効にする。 WinAppDriver.exeを実行する。 C:\Program Files (x86)\Windows Application Driver\WinAppDriver.exe テストコード作成 Visual Studioで単体テストプロジェクトを作成する。 Nugetパッケージマネージャーで「Appium
AWS Lambda に対するユニットテスト(以下、UT)で気をつけていることを言語化して、記録に残します。 結論 はじめに 実現したいこと 考えたこと 工夫したこと 具体例 処理内容 ディレクトリ構造 テストデータ Lambda Function テスト共通処理 テストコード まとめ 結論 AWSサービスに関わらない処理ステップを切り出して、先にテスト駆動開発で実装する、という考え方をしています。 はじめに AWS Lambda は、言わずと知れた FaaS(Function as a Service) です。 開発単位が関数であるために気軽につくりはじめることができますが、 心のままにコードを書いてしまうと、節々にAWSの要素が入り乱れてしまい、 結果としてUTができない成果物になってしまうことがありました。 こうなってしまうと、取りうる手段は二択です。 リファクタリングする そのまま
VBAにはユニットテストやリファクタリング機能がない・・・そんなふうに考えていた時期が俺にもありました - Qiita
はじめに ワルいけどVBAは開発環境としてあまりにも不完全すぎる。 VBAにはユニットテストがない リファクタリング機能がない 静的解析がない 以上の理由でVBAは開発環境として不完全だッ ※実際のところ、VBAUnitとかコードをエクスポートして静的解析とかできますが、今回はパス。 殺伐とした開発環境に救世主が!!! RubberduckはVBA6,VBA7 x86/x64,VB6の開発環境であるVBEを拡張するものです。 オープンソースで開発されており、以下のページからダウンロードが可能です。 https://github.com/rubberduck-vba/Rubberduck 上記からインストールすることで、VBEはRubberduckの機能を含んだものに拡張されます。 ※メニューとツールバーが追加されている Rubberduckの機能 コードメトリックスを表示する Rubber
こんにちは、Yutaです。 今回は単体テストの自動化実施方法についてです。 駆け出しエンジニアの皆さんは普段コードを 書いていらっしゃると思いますが、 テストコードもしっかり書いておりますでしょうか。 「うちは手動テストだから関係ないし、、、」 と思ったあなた！笑 今ではテストコードを書けるかということも エンジニアとして重要です。 ですが、確かに既存の手動テストをいきなり自動化させるのは、 なかなか骨が折れますよね、、、笑 なので、今回紹介する方法で、少しずつで構わないので、 単体テストを自動化させていきましょう。 なぜテストコードで自動化させるのか そもそもなぜ自動化させるのか、改めて目的を考えてみましょう。 目的としては、単体テストの自動化により、 開発にリソースを集中させ、人的ミスを撲滅させるためであると私は考えます。 人力によるテストでは、高い負荷がかかるため、何回もテストを実施
【Golang】Github actionsでカバレッジを取得しCodecovにアップロードする - Simple minds think alike
Go言語で作ったアプリケーションのGithubリポジトリでGithub actionsワークフローを設定し、 codecov にカバレッジを送る設定方法を紹介したいと思います。 codecov は、テストのコードカバレッジを取得してくれるツールです。テストスイートを実行した時にソースコードの実行箇所を視覚的に示してくれて、どこに新しいテストを書くべきか分かりやすくなります。 緑: テストスイートによってソースコードが実行されている箇所 黄: テストスイートによってソースコードが部分的に実行されている箇所（具体的には、真偽値が返るところで、 true か false のどちらかしか返っていない箇所） 赤: テストスイートによってソースコードが実行されていない箇所 忙しい時はテストコードを書くのが手抜きになったりするのですが、 codecov を使っているとカバレッジが定量的・視覚的に表現され
.NETの単体テストでMoqを使ってみる
Moqとは？ .NET環境の単体テストで使用する、外部モジュールのMock化(Stub化)パッケージです。 例えば、テスト対象のクラスがHTTPやシリアルポートで外部と通信していると、そのままでは単体テストを組むのは容易ではありません。(テスト用のサーバーを用意するなど） そういった、HTTP通信やシリアルポート通信をする部分をダミーのテスト用モジュールに置き換えるのがMoqです。 環境 Windows 10 Pro 2014 Visual Studio 2019 Version 16.6.3 言語：C# (.NET Framework 4.7.2) 単体テスト プロジェクト (.NET Framework) Moq 4.14.5 (NuGetからインストール) テスト対象クラス テスト対象クラスを、内部でシリアルポートで通信するクラスとします。 名前は、Communication として
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TDD研修 by t_wada さん を開催しました - Classi開発者ブログ
「単体テストの考え方/使い方」が主張するたった一つのこと
テーブル駆動テストを使った QA エンジニアとソフトウェアエンジニアの連携
第8回 脆いテスト ～継続的な変更と改善を阻むテストの原因と対策～ | gihyo.jp
#phpcon2021 ステップ実行だけじゃないXdebug / hello-xdebug
TypeScript + Storybook CSF3.0の書き方とユニットテストへの応用
Codecov - The Leading Code Coverage Solution
Poetryでプライベートリポジトリからインストールする3つの方法 - Sweet Escape
いつも忘れてしまうC0/C1/C2カバレッジまとめ
AAA を意識して単体テストを書く - Pepabo Tech Portal
Angular アプリケーションのユニットテスト環境をゼロから作る - とんかつ時々あんどーなつ
Jest CLI オプション · Jest
C#のMSTestでFine Code Coverageでカバレッジを計測する - Qiita
DIと単体テストと私: 緩やかな依存関係がもたらすメリット
C# 単体テストを作成、実行、カスタマイズする - Visual Studio (Windows)
Comparing xUnit.net to other frameworks
DRY vs DAMP in Unit Tests
Unit Testが実行できなくなった原因と対処【xUnit】
PythonのunittestのカバレッジをVSCode上に表示する - Qiita
Jestのカバレッジはどのように見ればよいのだろうか？ - Qiita
PhpStorm で PHPUnit をずっと実行している話 - BASEプロダクトチームブログ
WinAppDriverでテスト自動化：操作別テストコード - Qiita
AWS Lambdaに対するユニットテスト - public note
今日から使えるC#単体テスト自動化方法 | Fledgling Engineer Blog
www.watch.impress.co.jp
www.maruyoshi30.net
driveon43.com
anond.hatelabo.jp
tofun.kounes.net
xtech.nikkei.com