並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 110件

新着順 人気順

xUnitの検索結果1 - 40 件 / 110件

  • CTOが選ぶ、エンジニアのみなさんに個人的に読んでほしい本|藤村

    メリークリスマス!heyでCTOをやっている藤村です。ということで、これからエンジニアになる・いまエンジニアをしているみなさんに個人的に読んでほしい本をご紹介します。これを読んでおけばソフトウェア・エンジニアとして網羅的な基礎が身につく、とかいうセレクトではなく、あくまで個人的に読んでもらえると嬉しいな!というものを選びました。 ソフトウェア開発基礎編リー・コープランド『はじめて学ぶソフトウェアのテスト技法 』 テストの本です。昨今RSpec、XUnit系など自動テストのツールはすっかり普及し、ソフトウェアにテストコードをつけるのは当たり前の世の中になりました。しかし!テストケースをどう設計するか、何をテストすべきか、について体系的に学んだことがない、という方も実はいらっしゃるのでは。 この本はそういったソフトウェア・テスト一般についての教科書です。ここの知識はソフトウェア・エンジニアとし

      CTOが選ぶ、エンジニアのみなさんに個人的に読んでほしい本|藤村
    • プライベートメソッドのテストは書かないもの? - t-wadaのブログ

      この文章の背景 この文章はプライベートメソッドのテストを書くべきか否かに関する knsmr さんのご質問に対して 2013/03/13 に QA@IT で回答したものです。残念ながらQA@IT のサービス終了(2020/02/28)と共にアクセスできなくなってしまったため、運営を行っていたアイティメディア株式会社様、開発を行っていた永和システムマネジメント様、そして質問をされた knsmr さんに許可とご協力をいただき、当時の回答をサルベージしてブログに転載する運びとなりました。 プライベートメソッドのテストはよく議論になるテーマですので、当時の回答を再編集し、knsmr さんのご質問も含め、ご利用いただきやすいライセンス CC BY(クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0) で公開いたします。 目次 この文章の背景 目次 knsmr さんのご質問 私の回

        プライベートメソッドのテストは書かないもの? - t-wadaのブログ
      • 2021年の「オブジェクト指向」を考える

        きしださんが先日もたのしいお題を投下されていました。 出遅れましたがこのネタについて少し掘り下げてみます。 念のため個人的なスタンスをあらかじめ表明しておくと、オブジェクト指向に対してはそれなりに好意的ですが、別に時代の最先端だとかソフトウェア開発に必須の知識というほどではない(でも知っておくと便利というか、知らないと不便なこともあるかもしれないのでわざわざ避けるのはおすすめしない)というくらい温度感です。 オブジェクト指向 is 何 そもそも「オブジェクト指向」という言葉自体、座りの悪い言葉です。 意味が明確なのは「オブジェクト指向プログラミング(OOP)」、「オブジェクト指向プログラミング言語(OOPL)」、「オブジェクト指向設計(OOD)」「オブジェクト指向分析(OOA)」といった「オブジェクト指向なんとか」の方で、それらをふわっとまとめた(ような気がする)単語が「オブジェクト指向」

          2021年の「オブジェクト指向」を考える
        • 「自動テストとテスト駆動開発、その全体像」を執筆しました(Software Design 2022年3月号) - t-wadaのブログ

          【更新】寄稿した記事が Web に公開されました 技術評論社様のご厚意により、 Software Design 2022年3月号に寄稿した「自動テストとテスト駆動開発、その全体像」が gihyo.jp にて公開されました。誠にありがとうございます! gihyo.jp はじめに 2022年2月18日発売の Software Design 2022年3月号 にて、第2特集「そろそろはじめるテスト駆動開発」の第1章「自動テストとテスト駆動開発、その全体像」を執筆いたしました。第1章では、混同されることの多い自動テスト関係の概念を自動テスト、テストファースト、テスト駆動開発(TDD: Test-Driven Development)の3つの段階に分け、それぞれの効果や注意点を包括的に整理整頓しています。 ソフトウェアデザイン 2022年3月号 作者:大竹 章裕,瀬戸口 聡,庄司 勝哉,光成 滋生,

            「自動テストとテスト駆動開発、その全体像」を執筆しました(Software Design 2022年3月号) - t-wadaのブログ
          • テストでのデータベース単位の捉えかた - 日々常々

            データベース(に限らずあらゆる永続化リソース)を使用するテストをいかにして行うかはいつだって悩みの種です。この悩みは「どうやったらデータベースを使用するテストを行えるかわからない」ではなく「なんとかやってるけど、不満のようなものがある」というものになるかと思います。 やりかたはたくさんあるのですが、その優劣は条件なしに比較する意味がないくらい、条件に依存します。どんな選択肢も「この条件なら最適」と言えてしまうだけに、広いコンテキストで「こうするのがベスト」とも言いづらいのです。 前提 xUnit Test Patterns を下敷きにします。 ユニットテストでの話です。他でもある程度通じます。 具象イメージはSpringBootを使用するWebアプリケーションです。そこまでべったりな内容ではありませんが、背景にあるとご理解ください。他でもそれなりに通じます。 データベースを使用するテストで

              テストでのデータベース単位の捉えかた - 日々常々
            • なぜJestのmockライブラリに混乱してしまうのか? - Qiita

              はじめに JavaScriptのモックライブラリでは、 sinon などが有名であるが、テスティングフレームワークに Jest を使ってるならば Jest組み込みのモックライブラリで済ませたほうが学習コスト少なくて済むだろうと思える。 しかし、 sinon の感覚でJestのモックライブラリを使おうとすると違和感というのか、モックへの考え方の違いに気づかされる。 ということで今回は、Jestのモックライブラリの考え方と使い方を整理していきたいと思う。 モックの用語整理とJestモックライブラリの位置づけ モックと一言でいっても、それが指す内容は微妙に異なる。 ここでは、モックを 広義のMock Object と 狭義のMock Object と分けて整理してくれているテスト駆動開発を参考に用語を整理する。 テスト駆動開発では、モック用語を、下図のとおり、テストダブルとそのサブクラスとして

                なぜJestのmockライブラリに混乱してしまうのか? - Qiita
              • 「引き継ぎできない!」から始まった私のスクラム - 川口恭伸の「はじめてのアジャイル」 - Agile Journey

                Agile Journeyをご覧のみなさん、はじめまして。川口恭伸(@kawaguti)と申します。 私はアジャイル開発やスクラムに関する知識を提供し、モダンなソフトウェア開発の要素の研究、プロダクト開発の進め方やチームの目標設定など、さまざまな領域でのコンサルティングを手掛けています。 また、アギレルゴコンサルティング株式会社においてシニアアジャイルコーチとして活動しており、一般社団法人スクラムギャザリング東京実行委員会と一般社団法人DevOpsDays Tokyoの代表理事も務めています。さらに、コミュニティ活動としては、毎週水曜日に品川アジャイルに参加しており、RSGT、スクラムフェス、DevOpsDaysといったカンファレンスでのスタッフワークも担当しています。 このように、ほぼ公私の境なくアジャイルやスクラムを基にした活動を長く行っていますが、本稿では、私がスクラムを始めるまでの

                  「引き継ぎできない!」から始まった私のスクラム - 川口恭伸の「はじめてのアジャイル」 - Agile Journey
                • Lambdaのテスト領域に関する技術共有会を開催しました | DevelopersIO

                  はじめに CX事業本部の佐藤智樹です。 今回は先月中頃に実施したLambdaのテスト領域に関する技術共有会の資料と当日にいただいた意見を紹介します。技術共有会自体はお客様含め5人ほどで実施予定でしたが、社内の方を誘ったところ15人程と大人数でディスカッションしながら知識を深めました。有意義な時間となったのでブログで共有します。 本記事はLambdaに対してどのようなテストをすべきか、Lambdaでこれからテストを書くがどうやれば良いか悩んでいる方などは参考になるかと思います。いくつか紹介するテストパターンのメリット/デメリットもあげるので、テスト選定の上で参考にしてください。 例となる題材がなければ抽象的な話ばかりになり分かりづらくなるので、今回は以下のIoTデータ収集システムをベースにどうテストを書いていくか検討します。IoTデバイスからきたデータをRDSに保存するシステムです。色々書い

                    Lambdaのテスト領域に関する技術共有会を開催しました | DevelopersIO
                  • テストコードを負債化させない上手な付き合い方 / Test Code Management

                    XUnit Test Patterns に筆者の経験則を落とし込んでまとめています。 2024/01/25 TechBrew in 東京 〜技術的負債と共に歩むプロダクトの成長〜 の登壇資料です。 https://findy.connpass.com/event/306451/

                      テストコードを負債化させない上手な付き合い方 / Test Code Management
                    • 技術的負債とならないテストコードを書くために考えること - Qiita

                      概要 プロダクト開発を行う上で、テストコードは重要な要素であるかと思います。 ユニットテストコードを書くことで、クラス単位の動作保証を行うことが出来ます。また、E2Eテストやインテグレーションテストを書くことで、DBアクセスや外部連携を含めた、プロダクトにおける一気通貫の動作を確認することが可能になります。 作成したテストコードは、CICDと組み合わせて、自動テストとして定期的に実行させます。これにより、既存のソースコードを変更した際の品質を (ある一定レベルにおいてですが) 担保することが出来るようになります。結果として、開発メンバーは積極的なリファクタリングを行えるようになり、健全な開発のライフサイクルが回る・・・という流れになります。 テストコードも、プロダクションコードと同様に、継続的に保守・開発していく必要があり、一定のお作法に則って開発していく必要があります。無秩序で設計が不十

                        技術的負債とならないテストコードを書くために考えること - Qiita
                      • t-wadaさんの開発生産性の観点から考える自動テストを聴講して悔い改めたこと - shoudaiの日記

                        t-wadaさんのセッションを聴講したこと 2024/6/29に開発生産性カンファレンスに参加してきました。 その中でなんでもかんでもE2Eテストでも実行してしまうことがあるけど、 悪ではないけどデメリットもあるよ。って話がありました。 speakerdeck.com スライドP47のアイスクリームコーンとピラミッドの図だけはご参照ください。 頭の中にその図が残っているため、前提になってます。 セッションの概要 アジェンダからざっくりお話は 信頼性の高い 誤検知(テストとして正常であるはずがエラーになってしまう)や見逃し(エラーがあっても正常にしてしまう)がないこと 実行結果 実行結果値だしたり、エラー原因が特定しやすいテストを書くこと 短い時間で到達 確認したい観点を確認できる最小のテストスコープ(単体テスト、結合テストなどの粒度)でテストできるようにすること 状態に保つ 短い時間で到達

                          t-wadaさんの開発生産性の観点から考える自動テストを聴講して悔い改めたこと - shoudaiの日記
                        • RSpecの作者が振り返る歴史(翻訳)|TechRacho by BPS株式会社

                          概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: History of RSpec – Steven R. Baker 原文公開日: 2021/05/09 著者: Steven R. Baker 日本語タイトルは内容に即したものにしました。 私がTDD(テスト駆動開発)をチームで教え始めたのは2001年のことでした。当時のTDDはまだかなり新しい概念でしたので、テストを自動化したチームもほとんどなく、XP(エクストリームプログラミング)やTDDについて聞いたことがある人も皆無でした。テストを最初に書くことで設計を進めるという概念は当時まったく知られていなかったので、TDDを理解するのに皆とても苦労していました(20年経った今でも、この事実が完全に変わったとは言えません)。 思い返せば、あの当時は厳しい状況でした。最善を尽くしてTDDの概念を説明し、どうにかしてチームの関心を惹こう

                            RSpecの作者が振り返る歴史(翻訳)|TechRacho by BPS株式会社
                          • Tests as Documentation - たにしきんぐダム

                            production code の設計についてはよく議論される一方、ユニットテストをどう書くべきかについてはあまり議論されることが少なく。とにかくカバレッジが高ければヨシみたいな感じで軽く扱われていることが多い気がする。 その結果、テストを書くときやとりわけテストを追加するときに "良くない" 方法でテストを追加/拡張してしまい、メンテナンスしにくく壊れやすい・(未来の自分でも)読んでも何を検証しているのか分からない、テストが落ちても不安だけを煽り何が問題なのか分からない、技術的負債が誕生してしまう。 詳しいことは本 ( XUnit Test Patterns など? 詳しい人は僕に紹介してください)を読んだりチームメンバーと議論するのが良いと思うが、この記事を読んでテストの書き方に対する意識を啓発できたらなと思っている。 理想を述べるのは簡単だけど現実は大変、頑張ろう introduct

                              Tests as Documentation - たにしきんぐダム
                            • 【Ruby版】xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - give IT a try

                              はじめに テストダブル(Test Double)について、わかりやすく解説した技術記事はないかな〜と探していたところ、こちらのブログ記事を見つけました。 goyoki.hatenablog.com とても詳しく解説されていたので、まさに打ってつけだったのですが、ふだん僕はRubyを使っているのでサンプルコードをRubyにしてみたいな〜と思いました。 そこで今回のエントリでは、原著者の id:goyoki さんの許諾をいただいた上で、上記のブログ記事の説明文を維持したまま、サンプルコードだけをRubyに書き直してみました。(goyokiさん、どうもありがとうございます!) ただし、Ruby版のコードにあわせて説明文を改変した箇所もいくつかあります。 それでは以下がRuby版の「xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の

                                【Ruby版】xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - give IT a try
                              • 自動テスト全体の信頼性を維持するためにはどうするか 「ブレない基準でピラミッドを作り、スモールに切り出していく」

                                Qiita Conferenceは、ソフトウェア開発者が集まり、最新の技術や最先端の挑戦・ソフトウェアの未来についての考えや知見を共有し、つながる場を創出する、「Qiita」が開催するオンライン技術カンファレンスです。ここで和田卓人氏が「サバンナ便り - 自動テストに関する連載で得られた知見のまとめ(2023年5月版) 」をテーマに登壇。最後に、テストダブルとテストピラミッド、サイズダウン戦略について話します。 テスト用に使う偽物「テストダブル」 和田卓人氏:じゃあ次。テストダブルの話にいきます。「忠実性と決定性のトレードオフを理解しよう」という点です。これはもうちょっとあとにまた出てきます。 テストダブルというもので、モックオブジェクトとかスタブとかを使って、本物ではない偽物をテスト用に使ってテストをすることはよくありますよね。 データベースの偽物とか外部システムの偽物とか、Amazon

                                  自動テスト全体の信頼性を維持するためにはどうするか 「ブレない基準でピラミッドを作り、スモールに切り出していく」
                                • 『iOSテスト全書』を共著した話。あるいは『教科書本』との違い。 - ペンギン村 Tech Blog

                                  どうも、最近はRabi-Libiという弾幕アクションゲームをやっているtobi462です。 というわけで、PEAKSから『iOSテスト全書』の電子版が正式リリースされました。 peaks.cc おそらく製本版も今月中には発送されるかと思います。 (ところで一般販売はされるのでしょうか?私、気になります!) 追記:一般販売が開始されました! iOSテスト全書 著者: 松尾 和昭,細沼 祐介,田中 賢治,平田 敏之,玉城 信悟, 製本版,電子版 PEAKSで購入する そんなわけで、個人的にどういう想いを込めて執筆したのか、みたいなことを自分なりに振り返りながら書いてみたいと思います。 担当した章 私は著者陣の一人として、以下の章の執筆を担当させていただきました。 第2章:ユニットテスト(概要) 第4章:ユニットテスト(Quick / Nimble 編) 第5章:BDDによるアプリ開発 なお、第

                                    『iOSテスト全書』を共著した話。あるいは『教科書本』との違い。 - ペンギン村 Tech Blog
                                  • APIテスト アーキテクチャ

                                    テックリードとして2つのプロジェクトのテスト自動化を推進しています(本業)。 この記事では、プロジェクトでの経験を踏まえ、APIテストの位置づけ、システム上のスコープ、2つの方式について説明します。 この記事の目的 これから新規/既存WebシステムのAPIテストを自動化する人に向けて、APIテストの位置づけ・システム上のスコープ・2つの方式を紹介し、よりよいアーキテクチャを選択してもらうこと 想定読者 この記事は、テストピラミッドの考え方を採用し、以下のような方針でテスト自動化を進めることが前提です。 ユニットテスト、UIテスト、APIテストのように、粒度・観点の違うテストをバランスよく用いて、品質を効率的に担保する ユニットテストなどのより小さい粒度のテストで品質の大部分をカバーし、APIテスト、E2Eテストなどのより大きい粒度のテストをできる限り削減する 上記の前提を読んでも理解できな

                                      APIテスト アーキテクチャ
                                    • Rustでマイクロサービス開発はじめました - EmotionTechテックブログ

                                      はじめに こんにちは、テックリードのかどたみです。 「冷やし〇〇はじめました」の幟が街を彩って久しくも、まだまだ暑い日が続きますね。 突然ですが、皆さんは今夏新しくはじめたことはありますか? 弊社ではタイトルの通りRustでマイクロサービスの開発をはじめました。 この記事では、マイクロサービス化やRustに至った考えとRustで開発をしてみた感想を述べたいと思います。 なぜマイクロサービス化するのか? 弊社ではサービス開始当初からRuby on Railsを用いて開発が進められ、現在でも機能の追加が続いています。モノリスとしてどんどん大きくなっているのですが、大きくなることによって以下のような課題が出てきています。 新しいメンバーがコードを把握するのにかなり時間を要する 改修の影響範囲が大きくなり、見積もり難度が上がっている テストやビルドに時間がかかり、細かな修正でもリリースのコストが高

                                        Rustでマイクロサービス開発はじめました - EmotionTechテックブログ
                                      • 自動テストの実行時間を大幅短縮!分析と最適化の実践法

                                        Thinkings 株式会社では、sonar ATS の開発で自動テストを導入しています。過去に CI の実行時間を大幅に削減したことで全体の実行時間は短くなりました。自動テストの速度改善は手が回っていなかったので、CI 実行時間のボトルネックになっていました。今回は自動テストの実行時間を短縮するためにどうやって分析を行ってテストコードを改善したかについて説明します。 開発環境 開発環境は次の通りです。今回はバックエンドの改善内容について説明します。 Visual Studio 2022 .NET Framework 4.6.2 C# xUnit.net 実行時間の分析方法について まずは、自動テストのボトルネックを分析する方法について説明します。前回もお話しましたが、弊社では CI/CD ツールに Jenkins を使用しています。自動テストは1日に数回実行しており、その実行結果をアップ

                                          自動テストの実行時間を大幅短縮!分析と最適化の実践法
                                        • 単体テストの考え方/使い方 社内読書会をしました - BASEプロダクトチームブログ

                                          この記事はBASE アドベントカレンダー 2023の24日目の記事です。 基盤グループ エンジニアの田中 (@tenkoma) です。 2023年5月から8月にかけて、書籍「単体テストの考え方/使い方」の読書会を社内有志でしました。 読書会の様子や感想をまとめます。 書籍「単体テストの考え方/使い方」について 単体テストの考え方/使い方 プロジェクトの持続可能な成長を実現するための戦略 | マイナビブックス 単体テストの考え方/使い方 プロジェクトの持続可能な成長を実現するための戦略 | 達人出版会 2022年12月に出版されました。 2020年1月に出版されたUnit Testing Principles, Practices, and Patterns (Manning)の翻訳書です。 単体テストについて定義し、その価値を最大限に高めるための方法について解説されています。 書籍への期待

                                            単体テストの考え方/使い方 社内読書会をしました - BASEプロダクトチームブログ
                                          • Ruby コードレシピ集の感想と思い出 - ANDPAD Tech Blog

                                            こんにちは hsbt です。前回の仕事報告から3ヶ月ほどの間にシンガポールで開催された RDRC 2024 に登壇したり、Ruby のリリースワークフローの整備をしたりと、引き続き Ruby の開発に時間を費やしている日々でした。 今回は「Ruby コードレシピ集」という本を著者の皆さんと技術評論社様からご恵贈頂いたので、内容や感想を紹介したいと思います。 コードレシピ集と私の関わり 本書は私が前職である GMO ペパボに在籍していた3年前から企画段階に関わっていました。当時、技術評論社の担当の方から他の言語を学んだ人が Ruby を書くときに手元において使えるレシピ集となる本を出したいという提案をうけ、GMO ペパボの社内でシニア Ruby プログラマーを募って、企画をスタートさせました。 私はあくまでもオブザーバーとして関わり、著者である3名が毎週のように目次を持ち寄って進行していたと

                                              Ruby コードレシピ集の感想と思い出 - ANDPAD Tech Blog
                                            • テスト駆動開発(TDD)ハンズオンのすすめ - RAKUS Developers Blog | ラクス エンジニアブログ

                                              こんにちは、あるいはこんばんは。すぱ..すぱらしいサーバサイドのエンジニアの(@taclose)です☆ 弊社では先日テスト駆動開発(以降、TDDと呼ぶ)ハンズオン勉強会を開催しました! 今回の記事の内容はズバリ2つ 誤解してる!?テスト駆動開発の良さ!学ぶ事の意味! TDDハンズオン勉強会を開催する意図や実施内容、感想! 読者のターゲットは TDDを誤解している人 TDDハンズオン勉強会を弊社でもやろう!とか思ってる人 を想定していますっ。 誤解されがちなTDD、記事にするには書ききれないTDD...なるべく小難しい内容は省いて興味を持ってもらうための記事を書いてみようと思います! テスト駆動開発(TDD)は良い物だ! テスト駆動開発(TDD)とは何か? TDDに対する誤解 TDDハンズオンについて TDDハンズオンの趣旨 TDDハンズオンの計画 事前準備 スケジュールと概要 TDDハンズ

                                                テスト駆動開発(TDD)ハンズオンのすすめ - RAKUS Developers Blog | ラクス エンジニアブログ
                                              • アイスクリームコーンからテストピラミッドへ 和田卓人氏が考える効果的な自動テスト戦略の構築法

                                                ソフトウェアエンジニアリングの第一人者・和田卓人氏が、効果的な自動テスト戦略の構築について解説しました。アイスクリームコーン型からテストピラミッド型への移行の重要性を強調し、その実践的な方法を提示。E2Eテストの過剰投資への警鐘を鳴らすとともに、テストダブルの適切な活用法や良質な設計の必要性に言及しました。前回の記事はこちら。 アイスクリームコーンからピラミッドへの移行 和田卓人氏:ということで、「じゃあ、どうやってピラミッドを作っていこうか?」っていう話になるわけですね。多くの現場では、最初はアイスクリームコーンから始まります。別にそれは悪いことじゃありません。 いきなり最初からきれいにピラミッドを作れる組織ばっかりかというと、そんなことはないですよね。基本的に、難しいです。テスト容易性とは何かってわかっていないとピラミッドは最初から作れません。なので、最初は自動テストをがんばっていると

                                                  アイスクリームコーンからテストピラミッドへ 和田卓人氏が考える効果的な自動テスト戦略の構築法
                                                • 手間をかけない 頑張らない ファーストペンギンは否定しない XP祭りはアジャイルなイベントの実践 - Agile Journey

                                                  アジャイルソフトウェア開発手法の先駆けともいえるXP(eXtreme Programming)の名を冠して2002年から20年以上にわたり毎年開催されているXP祭り。2023年はオンラインの講演とオンサイトでのワークショップによるハイブリッド形式で、9月30日(土)に開催が予定されています。 ▶ XP祭り2023 - xpjug.com/xp2023/ コミュニティ主体によるカンファレンス開催が国内でまだ珍しかったころにスタートし、企業によるスポンサードもほぼなく、参加費も登壇料も全て無料、セッションだけでなくスタッフも毎年公募して入れ替える素朴な運営を続けながら、和田卓人さんや平鍋健児さんといった著名なエンジニアも登壇し、ソフトウェア開発について多くの示唆を与えてきたこのイベントはどのように続いてきたのでしょうか。 世界的にもアジャイルが広まりはじめた立ち上げ当初を知る小井土亨さんと、2

                                                    手間をかけない 頑張らない ファーストペンギンは否定しない XP祭りはアジャイルなイベントの実践 - Agile Journey
                                                  • Software Design連載 2021年11月号 Robot FrameworkでE2Eテストを自動化する - MonotaRO Tech Blog

                                                    最初に少しイベントの宣伝 こんにちは。金谷です。 Software Designに連載させていただいております「Pythonモダン化計画」は、前半の4回で、それぞれの局面に合ったテスト手法を用いることで変更容易性を確保する話をしてきました。 前半の4回すべてに出てきたツールにJenkinsさんがいて、何らかのかたちで自動化されています。 モノタロウにおけるモダン化計画に不可欠な存在のJenkinsさん。 なんとこのたび、Jenkins Day Japan 2021というイベントで、Jenkinsの活用事例を発表させていただくことになりました。 「モノタロウの開発・リリースサイクルを支えるJenkinsの活用事例」という内容で金谷が発表させていただきます。 詳細とお申込みは、下記のURLからご覧ください。 cloudbees.techmatrix.jp では本題に入ります。 本記事の初出は、

                                                      Software Design連載 2021年11月号 Robot FrameworkでE2Eテストを自動化する - MonotaRO Tech Blog
                                                    • iOS開発でテストを書くときのTipsやメモ

                                                      Select the tests you want to run by using CTRL or SHIFT, right-click and select “Run X Test Methods”. この記事では Test Navigator で実行したいテストだけ複数選択して実行できる方法も紹介されていて、これもたまに使う。 XCTAssertEqual は expectedが先か?actualが先か? この記事で少し言及があってふと気になった。 特に決まっている感じは無い? XCTest だと actual が先の方が多い? なお実際にはどちらかと言うより、↑記事で言われている通りプロジェクトで統一されていることの方が大事だと思う。 xUnit Patterns だと expected, actual の順。 XCTAssertEqualのドキュメントにあるコードだと actual

                                                        iOS開発でテストを書くときのTipsやメモ
                                                      • NTTコムウェア C+ | ITジャーナリストや現役書店員、編集者が選ぶ デジタル人材のためのブックレビュー 第20回:『ソフトウェアアーキテクチャ・ハードパーツ』、『テスト駆動開発』

                                                        トップコラムデジタル人材のためのブックレビューITジャーナリストや現役書店員、編集者が選ぶ デジタル人材のためのブックレビュー 第20回:『ソフトウェアアーキテクチャ・ハードパーツ』、『テスト駆動開発』 本書は『ソフトウェアアーキテクチャの基礎 ―― エンジニアリングに基づく体系的アプローチ』の続編にあたる書籍である。著者は前著の著者陣と新たに加わった2名の計4名。前著は「〜の基礎」というだけあって、概論からソフトスキルまで含む入門編のような位置づけだったが、そちらと比較すると本書は応用編と言える。 タイトルに含まれる「ハード」という言葉は、「難しい」という意味に加え、「堅い=変更するのが大変」という意味が込められている。つまり前著より難しいところに踏み込むわけで、いささかの手応えは感じるかもしれない。もっとも、読み手としてはとても気になるところを掘り下げてくれているため、前著は下準備で本

                                                          NTTコムウェア C+ | ITジャーナリストや現役書店員、編集者が選ぶ デジタル人材のためのブックレビュー 第20回:『ソフトウェアアーキテクチャ・ハードパーツ』、『テスト駆動開発』
                                                        • neue cc - 2022年(2024年)のC# Incremental Source Generator開発手法

                                                          このブログでもSource GeneratorやAnalyzerの開発手法に関しては定期的に触れてきていて、新しめだと 2020/12/15 - UnitGenerator - C# 9.0 SourceGeneratorによるValueObjectパターンの自動実装とSourceGenerator実装Tips 2021/05/07 - 2021年のC# Roslyn Analyzerの開発手法、或いはUnityでの利用法 という記事を出していますが、今回 MemoryPack の実装で比較的大規模にSource Generatorを使ってみたことで、より実践的なノウハウが手に入りました。また、開発環境も年々良くなっていることや、Unityのサポート状況も強化されているので、状況を一通りまとめてみようと思いました。Source Generatorは非常に強力で、今後必須の開発技法になるので

                                                          • The Legends of Runeterra CI/CD Pipeline

                                                            The Legends of Runeterra CI/CD Pipeline Hi, I’m Guy Kisel, and I’m a software engineer on Legends of Runeterra’s Production Engineering: Shared Tools, Automation, and Build team (PE:STAB for short). My team is responsible for solving cross-team shared client technology issues and increasing development efficiency. We focus on the areas that empower other teams to do more and protect the team from

                                                              The Legends of Runeterra CI/CD Pipeline
                                                            • 【英語スピーチの振り返り】日本で初開催のCakeFest 2019での登壇、スポンサーしました - BASEプロダクトチームブログ

                                                              こんにちは、はじめまして、お久しぶりです!BASE BANK株式会社にてソフトウェアエンジニアをしている東口(@hgsgtk)です。2019年11月7日(木)〜11月10日(日)にCakePHPの国際カンファレンス CakeFest 2019 が、日本で開催されました。私は、スピーカーとして参加したのですが、初めて30分強、国際カンファレンスで話す機会となったので、発表のために準備したことや反省点も踏まえて、参加レポートをお届けします。 CakeFest 2019 CakeFest 2019とは、PHP製ウェブフレームワークの一つであるCakePHPの国際カンファレンスです。年に1回開催されており、今回は初めて日本での開催となりました。 cakefest.org CakeFest 2019は、Workshop dayが2日、Conference dayが2日の合計4日間でした。Worksh

                                                                【英語スピーチの振り返り】日本で初開催のCakeFest 2019での登壇、スポンサーしました - BASEプロダクトチームブログ
                                                              • Building a self-contained game in C# under 8 kilobytes

                                                                NOTE: This article captures a point in time in the past. While the general information is still correct, the CoreRT project got folded into Native AOT publishing in .NET 7 and is now a supported part of .NET. The information about sizes is no longer accurate (and much better), neither is the information about support for dynamic code (both interpreter and JIT are unsupported). Read the full articl

                                                                  Building a self-contained game in C# under 8 kilobytes
                                                                • .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
                                                                  • How Async/Await Really Works in C# - .NET Blog

                                                                    Catch up on 16 sessions from .NET Conf: Focus on AI exploring how .NET developers can leverage AI libraries and features to build smarter applications, enhance productivity, and provide better user experiences. Several weeks ago, the .NET Blog featured a post What is .NET, and why should you choose it?. It provided a high-level overview of the platform, summarizing various components and design de

                                                                      How Async/Await Really Works in C# - .NET Blog
                                                                    • オープンソースの負荷テストツールのk6に入門 | DevelopersIO

                                                                      カオスカーニバルというイベントにてカオスエンジニアリングの実験を実行するときに利用できる負荷ツールを教えてもらったので試してみようと思います。 k6という名前の負荷テストツールで、オープンソース、無料、開発者中心、拡張可能です。 開発者向けの使いやすいAPIとCLIを備えていて、パフォーマンステストを自動化するために設計されています。 ユースケースとしては、 負荷テスト リソース消費を最小限に抑えるように最適化されており、高負荷テスト(スパイク、ストレス、ソークテスト)を実行するように設計されています パフォーマンスと総合的なモニタリング 少量の負荷でテストを実行して、実稼働環境のパフォーマンスと可用性を継続的に検証できます カオスと信頼性のテスト カオス実験の一部としてトラフィックをシミュレートしたり、k6のテストからトラフィックをトリガーすることができます といったものが挙げられていま

                                                                        オープンソースの負荷テストツールのk6に入門 | DevelopersIO
                                                                      • ConfigureAwait FAQ - .NET Blog

                                                                        Join us on September 18th as we dive deep into building world-class cloud native applications with .NET and Azure. .NET added async/await to the languages and libraries over seven years ago. In that time, it’s caught on like wildfire, not only across the .NET ecosystem, but also being replicated in a myriad of other languages and frameworks. It’s also seen a ton of improvements in .NET, in terms o

                                                                          ConfigureAwait FAQ - .NET Blog
                                                                        • 【感想】『ちょうぜつソフトウェア設計入門 ――PHPで理解するオブジェクト指向の活用』:圧倒的表紙詐欺からのちょうぜつ深い設計入門 - Rのつく財団入り口

                                                                          #ちょうぜつ本 を読み進める前に言っておく! (AA略 2022/12刊行、エンジニア界隈でも話題になった本。著者の田中ひさてるさんがSoftware Design誌に連載した記事+アドベントカレンダー掲載の話+カラーページに同雑誌のちょうぜつエンジニアめもりーちゃんの連載分も掲載した、ソフトウェアの設計を深く深く追求した本となっています。 表紙のキャラはちょうぜつエンジニアめもりーちゃん(銀髪?ロング姫カットの右側の子)とゆにっとさん(緑髪ショートにマリンルックの左の子)をメインに、ちょうぜつ技術書らしからぬ表紙。 最初は「オッコンピュータ書籍に時々ある萌え絵の表紙でオタク系エンジニャ〜を釣るタイプの本でゴザルな。拙者こういう本もイケるクチでござるよデュフ〜」的なちょうぜつ軽い感覚で読み始めたのですが... #ちょうぜつ本 を読み進める前に言っておく! (AA略 ちょうぜつエンジニアメモ

                                                                            【感想】『ちょうぜつソフトウェア設計入門 ――PHPで理解するオブジェクト指向の活用』:圧倒的表紙詐欺からのちょうぜつ深い設計入門 - Rのつく財団入り口
                                                                          • プライベートメソッドをテストすべきか

                                                                            「すべきでない」というのがたぶん多数派。テストすべきでない理由としてだいたい次の理由があげられる。 プライベートなメソッドや関数をテストする必要は無いと考えています。プライベートなメソッドは、実装の詳細であるからです。 多くの場合、そのクラスのパブリックメソッド経由でプライベートメソッドのテストも同時に行えます。 プライベートメソッドのテストは書かないもの? - t-wadaのブログ ほとんどの場合、プライベート メソッドをテストする必要はありません。 プライベート メソッドは実装の詳細です。 プライベート メソッドがある場合は、パブリック メソッドを見つけて、そのメソッドに対してテストを記述します。 単体テストを記述するためのベスト プラクティス - .NET | Microsoft Docs 「プライベートメソッドはテストするな」と強く主張されるのは、ケント・ベックの影響もあるかもしれ

                                                                              プライベートメソッドをテストすべきか
                                                                            • Announcing C# Dev Kit for Visual Studio Code - Visual Studio Blog

                                                                              Building new functionality, writing unit tests, and learning new technologies has never been easier or more fun. We are thrilled to announce the preview release of C# Dev Kit, a new Visual Studio Code extension that brings an improved editor-first C# development experience to Linux, macOS, and Windows. The C# Dev Kit is designed to enhance your C# productivity when you’re working in VS Code. It wo

                                                                                Announcing C# Dev Kit for Visual Studio Code - Visual Studio Blog
                                                                              • .NET 6からのC# Incremental Source Generatorの開発入門

                                                                                本記事はもなふわすい~とる~むアドベントカレンダー 2021に登録しようと思ったら全部埋まっていた上にC#アドカレその1にも登録できませんでしたのでその2に登録することといたします。 25日の記事です。 筆者環境 Windows 10 Visual Studio 2022 version 17.0.3 .NET Compiler Platform SDK .NET 6.0.101 概要 当記事では昨年作ったEmbedResourceCSharpというSource GeneratorをIncremental Source Generator(以下ISG)に対応させ、Visual Studio 2022以前Roslyn version 3しかない環境でもNuget経由でインストールして動作するようにします。 背景 Source Generatorの失敗 .NET 5とC#9.0と共に華々しく登

                                                                                  .NET 6からのC# Incremental Source Generatorの開発入門
                                                                                • Unit Testing is Overrated • Oleksii Holub

                                                                                  As Russia wages a genocidal war against my country, I'm grateful to everyone who continues to stand with Ukraine in our fight for freedom. The importance of testing in modern software development is really hard to overstate. Delivering a successful product is not something you do once and forget about, but is rather a continuous and recurring process. With every line of code that changes, software

                                                                                    Unit Testing is Overrated • Oleksii Holub