並び順

ブックマーク数

期間指定

  • から
  • まで

81 - 120 件 / 146件

新着順 人気順

xUnitの検索結果81 - 120 件 / 146件

  • #phpcon2021 ステップ実行だけじゃないXdebug / hello-xdebug

    PHP Conference Japan 2021での発表資料です https://fortee.jp/phpcon-2021/proposal/3ed8a69b-8618-4644-9a8c-655505078743

      #phpcon2021 ステップ実行だけじゃないXdebug / hello-xdebug
    • #yapcjapan YAPC::Kyoto 2023に行ってきた・喋ってきた - その手の平は尻もつかめるさ

      yapcjapan.org 2023年3月19日に開催されたYAPC::Kyoto 2023に参加してきました。もう2週間も前の話になるんですね......USに戻ってきてから色々あり、すっかりブログを書くのが遅くなってしまいました。 YAPC::Kyotoの様々な感想については「にゃんこ酒場.fm」で id:papix、id:karupanerura さんら運営の方々と喋ったPodcastが公開されているので是非お聴きくださいませ! nyanco-sakaba-fm.hatenablog.com 面白かったトーク ジョブキューシステムFireworqのアーキテクチャ設計と運用時のベストプラクティス id:tarao さんの発表。Fireworqが発表されたあたりって、スケーラビリティが高くなおかつ複数の言語から良い感じで使えるジョブキューのプロダクトについて「何使えば良いんだろうねえ」っ

        #yapcjapan YAPC::Kyoto 2023に行ってきた・喋ってきた - その手の平は尻もつかめるさ
      • 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

        • タクシーアプリ「GO」Android版へ自動テストを導入するまでの道のり - DeNA Testing Blog

          こんにちは、Androidチームの田熊(fgfgtkm)と外山(sumio)です。SWETのAndroidチームでは、Androidのプロダクトに対して自動テストのサポートをしています。 この度株式会社Mobility Technologiesが提供するタクシーアプリ「GO」のAndroid版に対する、おおよそ2年間に渡る取り組みが終了しました。 本記事では、この取り組みで行ってきた次の2点を紹介したいと思います。 「GO」のAndorid版に対してどのような自動テストを導入したか 開発チームに自動テストを定着させるまでにやったこと タクシーアプリ「GO」に対しての自動テスト導入 SWETのAndroidチームは「社内のAndroidエンジニアが自動テストを書くことを習慣化している」ことをゴールの1つとして、自動テストを普及させるための取り組みをしています。 その中でAndroidのテスト

            タクシーアプリ「GO」Android版へ自動テストを導入するまでの道のり - DeNA Testing Blog
          • Python Clickユニットテスト・レシピ集 - CLIではじめるテスト駆動開発(その1) - JX通信社エンジニアブログ

            「JX通信社Advent Calendar 2019」20日目の記事です。 こんにちは。2019年9月からJX通信社のエンジニアとなった鈴木(泰)です。好きな食べ物はオムライスです。 本日は、Python Clickユニットテスト・レシピ集 - CLIではじめるテスト駆動開発(その1)と題して、CLIのユニットテストのスニペットを書いてみたいと思います! "その1"とした理由は、アドカレに間に合わな(小声)・・・じゃなかった・・・この記事だけで全ての備忘録を列挙すると長くなりすぎてしまい、記事が読み難くなると判断したからです。 今後も引き続き少しづつ備忘録を紹介していければと思います。 はじめに 私はCLIをよく書きます。その理由は、バックエンドシステムの運用業務に携わっていることにあります。運用業務では様々な場面でCLIを作成します。私の場合、運用業務における手作業を自動化するため、バッ

            • モバイルアプリ用テスト自動化ツール「Appium 2.0」まもなく登場。ドライバーの分離、プラグインによる拡張対応など、新機能を開発者Jonathan Lipps氏が解説

              モバイルアプリ用テスト自動化ツール「Appium 2.0」まもなく登場。ドライバーの分離、プラグインによる拡張対応など、新機能を開発者Jonathan Lipps氏が解説 モバイルアプリケーションのテスト自動化ツールの代表的なツールが、オープンソースで開発されている「Appium」です。 そのAppiumの次期版となる「Appium 2.0」正式リリースが迫っています。Appium 2.0ではAppium本体から各プラットフォームへ対応するためのドライバが分離され、ドライバの開発が容易になります。 また、Appiumの機能を拡張するプラグイン機構も提供されるため、今後さまざまな拡張機能の登場が期待されるでしょう。 これらAppium 2.0の新機能について、AppiumのプロジェクトリードであるJonathan Lipps氏が、Appiumベースの商用サービスであるHeadSpinを国内で

                モバイルアプリ用テスト自動化ツール「Appium 2.0」まもなく登場。ドライバーの分離、プラグインによる拡張対応など、新機能を開発者Jonathan Lipps氏が解説
              • Writing unit tests in Golang Part 1: Introducing Testify

                Unit testing is a way of writing tests for the individual components (aka, the smallest part) of a program. The purpose of it is to validate that any piece of code is always working as expected. Moreover, unit testing has a lot of advantages such as improving the quality of code, providing documentation, also the code can be tested individually and doesn’t require another module in order for it to

                  Writing unit tests in Golang Part 1: Introducing Testify
                • [python] まだmockで消耗してるの?mockを理解するための3つのポイント

                  隣の席の人がテスト強化週間とか抜かしていたので自分もちゃんと理解するために なるべくわかりやすく まとめてみようと思います。 この記事は 2015 tech-yuruyuru アドベントカレンダー - 15日目の記事です。 2015 tech-yuruyuru アドベントカレンダー (2015/12/01 00:00〜)# 2015 #tech-yuruyuru アドベントカレンダー #tech-yuruyuru のアドベントカレンダーです。 テーマは特に決まっていません。好きなことを書いてください。 * 参加したい日の参加枠に参加登録してください * 2 日以上参加したい場合は、フィードで宣言してください ## カレンダー 1. @pjxiao: VPC のプライベートサブネットについて解説 2. @pjxiao: mDNS を使いローカルマシン内の仮想環境に接続する 3. @pjxia

                    [python] まだmockで消耗してるの?mockを理解するための3つのポイント
                  • PerlでスナップショットテストをするTest::Snapshotのご紹介 - Masteries

                    このエントリは, 「Perl Advent Calendar 2020」の9日目の記事です. qiita.com 昨日のエントリは, id:xtetsuji さんの「xargs や find と合わせて使う・代わりに使う Perl」でした. qiita.com 実は最近異動をしていた id:papix です. 異動後もPerlをモリモリ書いている日々ですが, 移動先のチームのプロダクトで同僚の id:mizdra が導入していた Test::Snapshot が便利だったので紹介します. metacpan.org Test::Snapshot Test::Snapshotは, その名の通り「スナップショットテスト」を提供するモジュールです. スナップショットテストとは, 予め「スナップショット」と呼ばれる期待値を生成しておき, テストを実行する際には実行結果とスナップショットを比較してテス

                      PerlでスナップショットテストをするTest::Snapshotのご紹介 - Masteries
                    • UPSIDERのこれからを担うFlutterアプリのアーキテクチャ - UPSIDER Techblog

                      こんにちは、UPSIDERで日々モバイルアプリ開発をしているふっくです。 UPSIDERでは今後、よりアプリ開発に注力し決済プラットフォームの中核的な役割を果たすことを目指しています。 今回は、今後の開発・運用を目指して考えたFlutterアプリ向けのアーキテクチャを紹介します。 ネイティブアプリの世界で触れてきた色々なアーキテクチャ・フレームワークを参考に、開発の後半でも順調にスケールさせることができるように、工夫を凝らしました。 本アーキテクチャで作ったサンプルアプリもあるので、ぜひ以下のリンクから見てみてください。 https://github.com/upsidr/flutter_architecture_blueprint デモはこちら https://upsidr.github.io/flutter_architecture_blueprint/ 対象読者 目指すところ 参考に

                        UPSIDERのこれからを担うFlutterアプリのアーキテクチャ - UPSIDER Techblog
                      • 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

                          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).
                        • Android でのコルーチンに関するベスト プラクティス  |  Kotlin  |  Android Developers

                          最新の Android UI に対する最新の宣言型アプローチと手軽な Kotlin を使って、少ないコードでアプリをすぐに動かすことができます。

                            Android でのコルーチンに関するベスト プラクティス  |  Kotlin  |  Android Developers
                          • GitHub - se2p/pynguin: The PYthoN General UnIt Test geNerator is a test-generation tool for Python

                            Pynguin (IPA: ˈpɪŋɡuiːn), the PYthoN General UnIt test geNerator, is a tool that allows developers to generate unit tests automatically. Testing software is often considered to be a tedious task. Thus, automated generation techniques have been proposed and mature tools exist—for statically typed languages, such as Java. There is, however, no fully-automated tool available that produces unit tests

                              GitHub - se2p/pynguin: The PYthoN General UnIt Test geNerator is a test-generation tool for Python
                            • Nature Remo開発におけるテストフレームワーク『Catch2』の活用方法を紹介します - Nature Engineering Blog

                              3日目! Nature Engineering Blog祭3日目は、ファームウェアエンジニアの中林 (id:tomo-wait-for-it-yuki) がお送りします。みなさま、自動テストはお好きですか?私は大好きです。手動で何度も同じことをテストするのは苦痛ですが、それをプログラミングのタスクに転化できるとなれば、最高ですよね! 今回はNature Remoのファームウェア開発で使用しているユニットテストフレームワーク『Catch2』の活用方法を紹介します。ESP-IDFで使えるテンプレートプロジェクトも用意してありますので、少し長いですが、最後まで楽しく読んでいただけると嬉しいです。 Catch2 Catch2は (modern) C++で書かれたユニットテストフレームワークです。Nature RemoのファームウェアはC言語で書いていますが、テストフレームワークはC++で書かれたも

                                Nature Remo開発におけるテストフレームワーク『Catch2』の活用方法を紹介します - Nature Engineering Blog
                              • GitHub - stackframe-projects/pgmock: In-memory Postgres for unit/E2E tests

                                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

                                  GitHub - stackframe-projects/pgmock: In-memory Postgres for unit/E2E tests
                                • フロントエンド:単体テストの観点

                                  対象読者 Jest や Testing Library のテストの書き方は理解しているが、何をテストすべきかわからないという方。 動機 近年、フロントエンドでもテストを書くことが重要視されるようになってきました。 テスト導入する際、共通で利用するコンポーネントや関数などをテストする記事は多いですが、何をテストすべきかについての記事が見当たらなかったため、私が意識してるテスト観点を執筆しようと思いました。 まず初めに各種テストの説明 単体テスト 関数やメソッドなどの最小単位の部分を個別にテストする手法のこと。 利用ツール例 Jest React-Testing-Library 結合テスト 複数のコンポーネントが、互いにうまく動作していることをテストする手法のこと。 利用ツール例 Jest React-Testing-Library End to End (E2E)テスト ユーザーが実際にシス

                                    フロントエンド:単体テストの観点
                                  • Hypothesisとpytestを使ってDjangoのユニットテストを書く - 何かを書き留める何か

                                    Hypothesisとは何か、プロパティベーステストとは何か Hypothesisは、Python向けのプロパティベーステストのライブラリである。 プロパティベーステストは、生成された多数の入力データに対してプロパティ(性質)が満たされるかどうかをテストする手法である。 HaskellのQuickCheckライブラリが初出で、現在は各プログラミング言語に移植されている。 従来のユニットテストは、ある程度固定したテストデータを指定してテストを行っていた。 その際、境界値分析などで妥当なパラメータを決定していた。 しかし、境界値分析が必ず通用するとは限らないし、人間が行う以上、ミスも発生する。 プロパティベーステストはデータを固定する代わりにそのデータが満たすプロパティを指定してテストを行う。 実際のテストケースはHypothesisがプロパティを満たすパラメータを決めて生成してくれる。 人力

                                      Hypothesisとpytestを使ってDjangoのユニットテストを書く - 何かを書き留める何か
                                    • Puppeteer と Coverage の話

                                      アドカレの 1 日目も Puppeteer の話を書いてたのだけど、別にその続きとかではまったくなくて、少し前に Puppeteer のカバレッジ関連でドハマリしたのでそれを書こうと思う。 背景他のところで散々書いてきているので、軽く触れる程度にしておくが、 https://github.com/reg-viz/storycap というツールの開発・メンテをしている。Puppeteer で Storybook をクローリングして各 Story を PNG 画像にする、ただそれだけの CLI だ。 このツールは画像ベースの回帰テストを自動化する目的で作られていて、日々の業務でも reg-suit や reg-cli などのツールと組み合わせて使っており、僕自身も前職の頃から世話になっている CLI だ。 自動テストの一環として Storycap を使っている関係上、Storybook をコン

                                        Puppeteer と Coverage の話
                                      • .Net 5 時代のテストフレームワーク比較 - Qiita

                                        この記事は C# Advent Calendar 2020 の 8 日目の記事です。 Microsoft 公式ドキュメント .NET でのテスト - .NET Core | Microsoft Docs に記載されている主要な三つの xUnit, NUnit, MSTest フレームワークを比較してみます。 結論、どれを使うべきか 新しいプロジェクトなら xUnit か NUnit を使うとよいと思います。過去のプロジェクトのマイグレーションならそのプロジェクトで使っているフレームワークでよいと思います。 Visual Studio からの実行や CLI (dotnet test) の実行、例外テストやデータドリブンテスト (Theory, DataSource) といった主要な機能はどのフレームワークでも対応しています。 個人的には xUnit の書き方が好きなので xUnit を使うこ

                                          .Net 5 時代のテストフレームワーク比較 - Qiita
                                        • Go Conference'19 Summer in Fukuoka にて登壇、費用対効果のいいユニットテストの考え方と実践について話しました #gocon - BASEプロダクトチームブログ

                                          こんにちは!BASE BANK株式会社 Dev Divisionでソフトウェアエンジニアをやっている東口(@hgsgtk)です!7月13日(土)に福岡で開催されたGo Conference'19 Summer in Fukuokaで登壇してきました。登壇内容や当日についてざっとレポートします。 Go Conference'19 Summer in Fukuoka - Go Conference'19 Summer in Fukuoka 登壇内容 Cost-effective Go unit test thinking and practices というタイトルで発表させていただきました。 個人的な観測では、Go界隈はユニットテストを書くことやテスタビリティの良いコードへの意識は強く、すでにユニットテストの技法に関する良資料はたくさんあるのですが、今回はWHYに着目した観点でプロポーザルを出

                                            Go Conference'19 Summer in Fukuoka にて登壇、費用対効果のいいユニットテストの考え方と実践について話しました #gocon - BASEプロダクトチームブログ
                                          • 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

                                              GitHub - plantain-00/type-coverage: A CLI tool to check type coverage for typescript code
                                            • Codecov - The Leading Code Coverage Solution

                                              Code Coverage: More Than a Metric. Codecov is the all-in-one code coverage reporting 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

                                                Codecov - The Leading Code Coverage Solution
                                              • Learn, improve and generate code with AI | Refraction

                                                with AIRefraction is a code generation tool for developers. It uses AI to generate code for you. You can use it to generate unit tests, documentation, refactor code and more. Generate code in Generate code using AI in 56 languages — ABAP, Ada, Apex, Assembly, Batch, C, C#, C++, CameLIGO, Clojure, Cobol, CoffeeScript, CSS, D Lang, Dart, Elixir, Erlang, F#, Fortran, Go, GraphQL, Groovy, Handlebars,

                                                  Learn, improve and generate code with AI | Refraction
                                                • AWS CDKにおける基本的なテストと実装方法を調べて試した | DevelopersIO

                                                  AWS CDKがGAされたので好きなサービスはAWS CDKと胸を張って言えるようになりました。 さてAWS DevDay Tokyo 2019でAWS CDKについてのセッションがありました。見ていない方はよろしければセッションレポートを見てください。 セッションの中でAWS CDKにおけるテスト方法について触れていました。今後自分でCDKライブラリを実装していく中でも避けられない内容なのでAWS公式ブログを見つつ実際に試してまとめてみました。 CDKのテストについて 今回記載するテストが指すものはCDKライブラリのテストです。 実際にライブラリが作成したCloudFormationテンプレートを元にCloudFormationスタックを作成するのはCDK CLIの責務です。 なのでCDK CLIから実際に作成するようなE2Eテストについては記載しません。またCDKライブラリのテストは通

                                                    AWS CDKにおける基本的なテストと実装方法を調べて試した | DevelopersIO
                                                  • TypeScript + Storybook CSF3.0の書き方とユニットテストへの応用

                                                    概要 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

                                                      TypeScript + Storybook CSF3.0の書き方とユニットテストへの応用
                                                    • 「ようこそ・・・『テストの世界』へ・・・」 - Qiita

                                                      Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up

                                                        「ようこそ・・・『テストの世界』へ・・・」 - Qiita
                                                      • 今がPython 2からPython 3へ移行するのにベストなタイミング:トークセッションレポート

                                                        今がPython 2からPython 3へ移行するのにベストなタイミング:トークセッションレポート:Pythonイベント Python 2のサポートが終了したら、今あるPython 2のコードはどうすればいいだろうか。悩ましい問題にさまざまな選択肢を与えてくれるセッションをレポート。

                                                          今がPython 2からPython 3へ移行するのにベストなタイミング:トークセッションレポート
                                                        • Rustでmockするならmockallで決まり!・・・でよろしいでしょうか?

                                                          Rustで DI (Dependency Injection)、してますか? 今日話題にするのはドメイン層でインターフェイスを定義してインフラ層でその実装を書くやつです。 例えばドメイン層で trait UserRepository を書いて、インフラ層で struct UserRepositoryImpl するやつです。 テストを書くとき、 struct UserRepositoryImpl はDBアクセスなどしてしまうので取り回しが悪いから、mock を作って fixture を入出力したいことありますよね。 Rustでそういうことやるなら mockall がオススメだよという記事です。 そんなに不満はないのですが、もしベターなやり方があったら記事末尾のコメントやTwitterやらもらえたら嬉しいです。 前職のFOLIO時代の同僚で現CADDiの むらみんさんの記事 に 外部通信のよう

                                                            Rustでmockするならmockallで決まり!・・・でよろしいでしょうか?
                                                          • ホワイトボックステストにおけるカバレッジとテストケース(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, カバレッ

                                                              ホワイトボックステストにおけるカバレッジとテストケース(C0, C1, C2, CDC, MC/DC, MCC) - ろぐれこーど
                                                            • いつも忘れてしまうC0/C1/C2カバレッジまとめ

                                                              カバレッジとは、検査網羅率(テストカバレージ) のことを指し、どれだけテストしたかの指標を表します。 ソフトウェアテストにおいて、カバレッジ(網羅率)を測定/分析することは、ソフトウェアの品質向上に非常に大きな意味があります。 コードのカバレッジを測定し、テストが実施されていないコード(通らないプログラム)を確認することにより、テストの妥当性を向上させることができます。 一般的には、単体テストでコードのカバレッジを測定し、テストの品質を測ります。 C++testなどの静的解析ツールも出ています。 その指標の中に、網羅率ごとのC0/C1/C2カバレッジがあります。 C0:命令網羅(ステートメント・カバレッジ) C1:分岐網羅(ブランチ・カバレッジ) C2:条件網羅(コンディション・カバレッジ) 文章にすると上記のとおりなのですが、毎回忘れてしまいがちなので、コードと照らし合わせてまとめておき

                                                                いつも忘れてしまうC0/C1/C2カバレッジまとめ
                                                              • Angular アプリケーションのユニットテスト環境をゼロから作る - とんかつ時々あんどーなつ

                                                                いつも 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

                                                                  Angular アプリケーションのユニットテスト環境をゼロから作る - とんかつ時々あんどーなつ
                                                                • 【Flutter】Widget テストの「あれ、これどうやるんだろう?」集 - Qiita

                                                                  この記事は Flutter Advent Calendar 2019 3日目 の記事です。 この記事では、自分が実際のアプリのコードで Widget テストをいろいろと書いていて「あれ、これどうやってテストすればいいんだろう?」とつまづいた部分を箇条書きで紹介したいと思います。 なるべく参考にしたサイトを載せているので、この記事はそれぞれの項目の入り口として、リンク先でより詳しく調べる感じで読んでいただけたらと思います。 Widget テストの基本 Widget テストの基本については、まずは公式ドキュメントをご参照ください。 WidgetTester の基本的な使い方や find による Widget の取得方法、テキスト入力やタップのエミュレート方法が簡潔に書かれています。 An introduction to widget testing | Flutter 本文 ↑ の公式ドキュメ

                                                                    【Flutter】Widget テストの「あれ、これどうやるんだろう?」集 - Qiita
                                                                  • C#のMSTestでFine Code Coverageでカバレッジを計測する - Qiita

                                                                    1. はじめに Visual Studio 2022 CommunityでMSTestのカバレッジを計測したい GUI上でソースコード内のカバレッジ状況を確認したい 2. 開発環境 C# MSTest Visual Studio 2022 Community Windows 11 3. Fine Code Coverageのインストール 下記サイトからDownloadボタンをクリックする ダウロードしたFineCodeCoverage2022.vsixをダブルクリックする Installボタンをクリックする Fine Code Coverageのインストールが完了する 4. カバレッジの取得 4.1. テスト対象メソッド

                                                                      C#のMSTestでFine Code Coverageでカバレッジを計測する - Qiita
                                                                    • 単体テストの考え方/使い方 まとめ

                                                                      著者は古典学派のスタイルを好んでいて、本書では古典学派の定義を採用している テスト対象の焦点をクラスに当てるのは間違っていて、1単位の振る舞いに焦点を当てなければいけない。 また、ロンドン学派のスタイルだと単体テストがテスト対象の内部的なコードと密接に結びつく傾向があるため、賛同できない。 3章 単体テストの構造的解析 AAAパターンという単体テストの構造を用いることで、全てのテストケースに対して簡潔で統一された構造を持たせることができる。また、この構造に慣れることで読みやすさが向上し、保守コストを下げることにつながる。 準備フェーズ(Arrange)フェーズ...ケースの事前条件を満たすように、テスト対象システムとその依存の状態を設定するフェーズ 実行(Act)フェーズ...テスト対象の振る舞いを実行するフェーズ 確認(Assert)フェーズ...実行した結果が想定した結果であることを確

                                                                        単体テストの考え方/使い方 まとめ
                                                                      • DIと単体テストと私: 緩やかな依存関係がもたらすメリット

                                                                        はじめに この記事は、アルサーガパートナーズ アドベントカレンダー2023、番外編の記事です。 「25日間のリレー」を成功に導いた素敵な記事たちがカレンダーに集まっていますので、よろしければ下記のリンクからご覧ください! この記事について 実務における最初の壁: DI 未経験からエンジニアとして実務に携わるようになると、誰しも「独学でやっていた時とは違うな」と感じることがたくさんあると思います。 私のサーバーサイドエンジニアとしてのキャリアはLaravelによる開発からスタートしたのですが、そんな私にとっての最初の「自己学習と実務の違い」の1つは、DI(Dependency Injection, 依存性注入) の概念が実装に利用されていること、でした。 すでに実装されている先輩方のコードを読めば「どう書けばいいか」はある程度すぐに把握できたものの、概念の理解を進めようとしても抽象的で難解な

                                                                          DIと単体テストと私: 緩やかな依存関係がもたらすメリット
                                                                        • C# 単体テストを作成、実行、カスタマイズする - Visual Studio (Windows)

                                                                          この記事では、マネージド コード用の Microsoft 単体テスト フレームワークと Visual Studio テスト エクスプローラーを使用して一連の単体テストを作成、実行、およびカスタマイズする手順について説明します。 開発中の C# プロジェクトで作業を開始し、そのコードを実行するテストを作成し、テストを実行し、結果を調べます。 次に、プロジェクト コードを変更し、テストを再実行します。 これらの手順を実行する前に、これらのタスクの概念の概要を確認したい場合は、「単体テストの基本」を参照してください。 テストするプロジェクトを作成する Visual Studio を開きます。 スタート ウィンドウで、 [新しいプロジェクトの作成] を選択します。 .NET 用の C# [コンソール アプリ] プロジェクト テンプレートを検索して選択し、[次へ] をクリックします。 Note [コ

                                                                            C# 単体テストを作成、実行、カスタマイズする - Visual Studio (Windows)
                                                                          • Comparing xUnit.net to other frameworks

                                                                            Comparing xUnit.net to other frameworks Table of Contents Attributes Assertions Attributes NUnit 3.x MSTest 15.x xUnit.net v2 Comments

                                                                            • Understanding the Python Mock Object Library – Real Python

                                                                              Watch Now This tutorial has a related video course created by the Real Python team. Watch it together with the written tutorial to deepen your understanding: Improve Your Tests With the Python Mock Object Library When you’re writing robust code, tests are essential for verifying that your application logic is correct, reliable, and efficient. However, the value of your tests depends on how well th

                                                                                Understanding the Python Mock Object Library – Real Python
                                                                              • AAA を意識して単体テストを書く - Pepabo Tech Portal

                                                                                こんにちは。EC事業部CREチームの rotelstift といいます。 私は主にカラーミーショップへのお客様からの技術的なお問い合わせに答え、希望された機能追加や発覚したバグの修正などを担当しています。 プログラマという職業に就いたのはペパボが1社目で35歳からというスロースターターですが、ペパボという会社はいるだけで成長できる会社だということを実感しています。 今回は、職業プログラマになる前はほとんど書いたことの無かったテストコードについて学んだこととして、読みやすさを劇的に改善する AAA (arrange, act, assert) と呼ばれる指針の解説をしたいと思います。 なお、この記事では RSpec を題材にした単体テストを扱います。 読みにくいテストコードの例 まず最初に、以下のテストコードを見てみましょう。なんか読みにくいと感じます。これが読みにくいのは AAA の各要素

                                                                                  AAA を意識して単体テストを書く - Pepabo Tech Portal
                                                                                • GitHub Actionsでカバレッジを可視化する

                                                                                  モチベーション 今携わっているプロダクトは、DDD+Clean Architectureなマイクロサービスとして構築しています。 自身の担当業務としてはレセプト関係になります。業務の特性上、複雑なビジネスルールをきっちりかっちり作らないといけないのでテストはかなり重点的に書いています。 ビジネスルール、ユースケースといったレイヤー化されたクラスにそれぞれテストを書いていくわけですが、ユースケースが依存しているビジネスルールが一つの場合など、いちいちユースケース単体でテストを書くのか?ということもあり、ケースによりますがテスト粒度を上げるという判断もしてたりします。 テストコーディング時に依存性を排除する為にモックを大量に使いますが、上記のような判断があったり、なかったりするとテストのカバー範囲の認識齟齬というものが出てきて最終的にカバレッジが漏れる事案が発生します。 またPRレビュー時にテ

                                                                                    GitHub Actionsでカバレッジを可視化する

                                                                                  新着記事