강의

멘토링

커뮤니티

BEST
Programming

/

Back-end

Java/Spring テストを追加したい開発者の間違いノート

Spring にテストを追加する方法を説明します。さらに、より自然なテストを行うために Spring の設計を変更する方法も学びます。

  • kok202
tdd
테스트
백엔드
TDD
Software Test
unittest
Spring
JPA

学習した受講者のレビュー

受講後に得られること

  • Spring にテストを追加する方法

  • テストに必要な概念

  • 自然なテストを行う方法

  • Mockito なしでテストする方法

  • 依存性とテスト可能性

  • ヘキサゴナル アーキテクチャ (Hexagonal Architecture) と設計

プロジェクト設計を進める
テストの本質をわかります!

Springにテストを入れる方法で始まり、アーキテクチャ講義で終わります!

テストに対する正しい意見を伝えるためには、結局アーキテクチャで終わらなければならないという考えをしたからです。

テストの基本的な概念を学び、Spring(スプリング)にテストを入れる方法を学びます。さらに、自然なテストができるようにスプリング設計を変更する方法を学びます。

だから、このような内容を学びます。

テスト
必要な理由

テストについて
基本概念

Springへ
テストを入れる
方法

Springデザイン
進化させる
方法

クリーン
アーキテクチャ

ヘキサゴナル
アーキテクチャ


ところで、もしかしたら、こんな気がしませんか?
テストに関する悩みと誤解

「テストを本当に切実に入れてみたいです。ところで…」

他の会社に通う友人は、時代のニーズに合わせてテストを着実に入れていきます。ところで、当社はテストを入れていません。遅れたくありません。勉強する意志もあります。ところで、とにかくこのレガシーシステムにテストコードをどのように入れなければならないか感がありません。

「H2を使ったテストに新物があります。」

H2を使ったテストは遅すぎてDBに依存しすぎます。すべてのテストがH2を使用しています。テストを回すのは負担になり、テストがh2を共有しているので、データが混乱しているときはテストが成功し、またあるときは失敗します。

「テストの必要性を感じられません。」

私たちのチームは、人がそれほど多くもなく、配布しながらもあまり不安を感じたことがありません。要件は時々変わります。しかし、TDDをどのようにしますか?テストは開発速度だけ遅れるだけだと思います。


テスト、私も同じ悩みをしました。

市中に出ているテスト関連の本やセミナーを探してみると、ほとんどそのままテストの利点、テストコードの作り方、JUnit、Mockito程度だけ話して終わります。例はちょうど入門者の好みに合うほど簡単な例だけです。だから最後に行って本を覆う時はこんな気がします。

  • 「一体これを現業でどのように書くのですか?」
  • 「Springにはテストをどのように入れるのですか?」
  • 「これはフレームワークがない状況で入れるテストだから簡単に入れられるのではないでしょうか?」

混乱しました。 H2を使ったJPAテスト...まあいいです。しかし、ElasticSearchやCassandraのようにテスト用のDBがない場合は、どのようにテストするのですか?さらに、H2を使ったテストは本当に致命的なほど遅かった。一日にも何度も回す負担でした。テストは頻繁に壊れてDBテーブルでも変更される日には関連するテストも芽生えて修正しなければならないので時間の無駄のようだと思います。

TDDを勉強するには、TDDから勉強しないでください。

その間、私の悩みは、アーキテクチャとDDDの勉強を始めながら、すべて解決されます。知っています。 TDDは常にホットです。ところで、TDDは本当に魅力的でありながらも難しい方法論です。 TDDをやったことのない組織でTDDが流行っているので、これからTDDとして開発しようとすればそれになるのでしょうか? TDDは、思ったより始める前に知っておくべき選手の知識と共感を必要とします。

したがって、TDDを勉強するには、TDDから勉強しないでください。テストを最初に勉強する必要があります。微積分をするには、方程式から扱うと知っておく必要があるようです。

テストに関する私の話を解きます!


テストに悩む
明快に解決します。

テストの必要性を感じない場合

テストの必要性が感じられない場合は、まだプロジェクトの規模がそれほど大きくないか、テストがなくても十分な開発能力と文化を備えているようです。テストは正解ではありません!テストがなかった時代にも素晴らしいプロジェクトがたくさん開発されました。テストは良いソフトウェアを得るためのツールなので、それ自体が目標ではありません。

テストで良いデザインを得る方法がわからない場合

テストをする方法だけに重すぎて勉強していたようです。 JUnitの使い方、Mockitoの使い方、h2を連動する方法を勉強することは明らかに意味のある勉強ですが、それがテストの本質ではありません。なぜテストをしなければならず、どのような目標があり、その目標を達成するためにどのように実践するべきかを学ぶ必要があります

テストフレームワークなしでテストする方法がわからない場合

テストフレームワークに関する質問も以前の質問と同じ答えです。もしあなたがTypescript + Nest.jsを書く環境にいるなら、どうやってテストしますか? Mockito、H2などのテストフレームワークなしでテストする方法を学ぶ必要があります。


Spring開発者に必須
テストを入れる方法
を学ぶ必要があります。

  • ✅実務と同等のテストを入れる方法をお知らせしません。
  • ✅Spring開発者に必要なテストを入れる方法を教えてください。
  • ✅ 同時に、なぜこのようにすべきかをお知らせします。

この原理に基づいた知識は、他のフレームワークでも一般的な知識です。 Nest.jsを使っていた、Swing UIを使っていた、Ginを使っていた…どこでも適用できる知識だと思います。

終章に行くと、設計に関する講義につながります。テストの価値を最大限に説明していただくためには設計についての内容が抜けてはいけないと考えたからです。

少なくとも私がブラウズ論国内のスプリングにテストを入れる方法を教えてくれる本や講義は見られないようです。すべて@Mock@Spyこれらのアノテーションを利用してmockingと依存性注入を受けてテストを作成します。しかし、もしこのようなMockライブラリが存在しない環境なら、どのようにテストするのでしょうか?本質的に、これらのアノテーションがなくてもテストする方法を知る必要があります!そして、テストすべき対象が何であるかを区別できる必要があります。


テストをテストのように追加する
方法をお知らせします!

テストの必要性がわかります。

フレームワークなしでスプリングにテストを入れる方法がわかります。

スプリングを使用するより良い方法がわかります。

レイヤードアーキテクチャからヘキサゴナルアーキテクチャへの移行方法を理解します。

オリエンテーション

テストを追加したい組織でTDDを導入するときに失敗する理由を見てください。一般的に、私がしているTDDはなぜ失敗するのかを見ています。テストを正しく理解することなく、テストをランダムに挿入し始めたときに発生する問題をまとめます。

テストの理論

基本的なテスト知識を勉強します。テストの必要性を共感し、テストと設計の相関関係を特定します。テストを作成しながら、開発者はどのような悩みをすべきかを理解します。最後に、自然なテストのためにTestabilityを向上させることについて説明します。

パート1 - トイプロジェクトベースのテストを適用

今後使用するトイプロジェクトを見てみましょう。そして、トイプロジェクトにうんざりしてテストを入れて、できるだけテストを入れてカバレッジ100%を達成してみます。このプロセスでは、h2、MockMvc、PowerMockなどの外部ライブラリを使用します。

最終的に作成されたテストを一緒に見て、回帰のバグだけをカバーするためのテストにはどのような問題があるかを見てください。

方向性ナビゲーション

私たちのトイプロジェクトにテストを入れたのがあまり良い方向ではない理由を一緒に見てみましょう。さらに、従来のレイヤードアーキテクチャの問題点についてまとめてみましょう。そしてどのように改善するか、講演者の意見を聞きます。

1部実機で無作為テストを入れるために苦労していたら、2部ではMockitoのような外部ライブラリなしで自然にMockする方法を身につけます。パート2の実践のために、事前にどのようにコードを変更するのかを見てみましょう。

パート2 - トイプロジェクト構造設計の改善

先進の方向性ナビゲーションを通じて得られたインサイトを当社のトイプロジェクトに導入します。この過程で構造的な変化を与え、設計を改善します。そしてこの過程で以下のような技法が使われます。

  • パッケージ構造の改善
  • ドメインと永続性オブジェクトを区別する
  • サービスロジックをドメインにインポートする
  • 外部連動を依存性を逆転する
  • テストを小型テストにする

進化するアーキテクチャ

テストと設計の相関関係を介してアーキテクチャを進化させる方法について説明します。レイヤードアーキテクチャがヘキサゴナルアーキテクチャにどのように変わるかを見てください。関心を分離しながら、開発者がドメインに集中する方法を学びます。


開発者として成長する
助けてほしい!

こんにちは、キム・ウグンです! 👋

現在カカオで働いていて、作るのが好きなので、退勤後も常に何かを開発しています。 「巨人の肩の上に立った小人」という言葉があります。私もやはり小さな小人だけですが、上がった巨人の成長に役立つように知識の対峙に努めています。多くのジュニア開発者の方々を指導した経験があり、皆様の成長をお手伝いできます。


Q&A 💬

Q. JUnitやMockitoの使い方は教えていただけませんか?

はい。理由は以下の通りです。

コンテキスト) 受講生の個人ごとにとどまる状況が異なります。すでに数回テストをした人がいる場合は、ライブラリを扱う熟練度が異なる場合があります。会社で使用しているライブラリがJUnitやMockitoではないかもしれない。バージョンが異なるため、提供しないインターフェイスが存在する可能性があります。代表的な例として、JUnit4は@ParameterizedTestをサポートしていません。さらに、前述のライブラリの使い方はそれほど難しくなく、関連する良い資料がすでに多すぎます。とにかく、Github READMEファイルを読んだり、公式ガイドを読んだりするだけで十分な使い方を学ぶことができると思います。したがって、使用法は重要な内容ではないと思いました。

テストデザイン) 特定のライブラリが提供する特定の機能を使ってテストする方法を学ぶことは、そのライブラリがなければそのテストを行うことができないということです。ツールやフレームワークよりテストをどのように設計し、どのようにテスト可能な構造に変えるかがより重要です。したがって、この講義はツールに集中しません。テストは開発プロセスの一部です。したがって、要件の分析、設計、配置、メンテナンスなどの文脈で考慮すべき点を確認することがより重要であると考えました。

Q. 以前の講義との違いは何がありますか?

カリキュラムを見ればわかりますが、以前の講義と重複する内容が多少あります。こうする必要があるということだけを説明するには説得力も不足して文脈を理解させてくれないので、独立して該当講義も受講できるよう講義を構成しました。だから必ず目次を確認してみて、重なる内容があるか確認してみてください。

率直な話で以前の講義をしっかり理解していたら、あえて重複して受講する必要はないと思います。以前のレッスンが構造的になぜこれを行うべきかを説明するレッスンであれば、今回のレッスンは実際にコードレベルでどのように解かれるかを扱うレッスンと見なすことができます。

Q. 受講前に知っておくべきことはありますか?

この講義は、スプリングやJPAを教えてくれる講義ではありません。受講者がおおよそのSpringとJPAに対処できることを前提に講義を行います。また、スプリングにテストを入れる方法をお知らせしていますが、本質的には依存性をどのように解放するかについて焦点を当てて進んでおり、必ずしも言語やフレームワークにこだわる内容ではないと思います。なお、専攻知識は必要ありません :)

💾受講前に確認してください!

  • 講義内の実習内容は、なるべく特定のライブラリやIDE、仕様に依存しないように構成しました。特定のバージョンにある特定の機能を活用した講義にならないよう努めました。それでも知らないので講演者のラップトップ構成が以下のような環境であることをお知らせします。
    • PCの仕様とオペレーティングシステム:MacBook Pro(16-inch、2019)とmacOS Monterey 12.6
    • IDE: IntelliJ IDEA 2021.3.2
    • Java 17、Spring Boot 3.0.1、JUnit 4.13.2、AssertJ 3.23.1
  • 受講生には40ページ内外のPPT資料12個を同梱しています。
  • このレッスンでは、プログラミング言語やスプリングを扱う方法などについては説明しません。
  • SpringとSpring Data JPAを一度でも扱ったユーザーに基づいて説明します。
  • Controller、Service、Repositoryについて知っていることを前提として説明します。
  • 講義に使用するトイプロジェクトをプレビューレッスンに解放しました。確認してみて理解できる程度なら大丈夫です。
  • PPTの一部をキャプチャして勉強した内容をブログに投稿することは許可されていますが、資料全体を個人のブログに共有することはできません。ご了承ください!
  • 以前の講義と重複する内容が多少あります。目次を確認して、重なっている内容を確認してみてください。
  • デモプロジェクトはこちらをご覧ください。

こんな方に
おすすめです

学習対象は
誰でしょう?

  • Springにテストを入れたい方

  • Spring にテストをどのように入れるべきか分からない方

  • 私が開発したSpringプロジェクトが正しい設計構造であるか混乱している人

  • テストを入れてみたけど失敗した方

  • H2のようなテストDBがないNoSQLにテストを入れたい方

前提知識、
必要でしょうか?

  • Java コードを理解できる方

  • Spring の基本 (Controller / Service / Repository について知っている方)

  • JPA を使用したことがある人

こんにちは
です。

3,612

受講生

270

受講レビュー

47

回答

4.9

講座評価

3

講座

  • (현) 카카오 백엔드 엔지니어
  • (수상) 🏆 공개 SW 개발자 대회 [2020 일반부문 / 금상_정보통신산업진흥원장상] 

 

현재 카카오에서 일하고 있고, 만드는 것을 좋아해서, 퇴근 후에도 항상 무언가를 개발하고 있습니다.

"거인의 어깨 위에 선 난쟁이"라는 말이 있습니다. 저 역시 한낱 작은 난쟁이일 뿐이지만, 올라탄 거인의 성장에 도움이 될 수 있도록 지식의 대물림을 위해 노력하고 있습니다. 다수의 주니어 개발자분들을 멘토링 한 경험이 있어서 여러분의 성장을 도와줄 수 있을 거예요. 

 

깃허브 > https://github.com/kok202
블로그 > https://kok202.tistory.com

カリキュラム

全体

25件 ∙ (6時間 20分)

講座資料(こうぎしりょう):

授業資料
講座掲載日: 
最終更新日: 

受講レビュー

全体

187件

4.9

187件の受講レビュー

  • f2idoijsdo님의 프로필 이미지
    f2idoijsdo

    受講レビュー 2

    平均評価 3.0

    5

    100% 受講後に作成

    私がインフラで決済したすべての講義をまとめて最高の講義だと断言する。 本からコピーせずに頭を掴んで作ったオリジナルカリキュラム構成、講義ごとにギュッと詰まっている卵爺たち、御影浮栄横説手説なし、すっきりしたコメントと文章、適切なスピードと明確な発火、テストという具現化された実践方法を通じて設計という大きな絵をそして、再設計という土台の下でテストを引き出す。悩み、繰り返し、改善し、開発をしてきたのか見えなくても見える。 インフラで講義した二つ聞いたわけではないが、この講義ほどA/Sをスタイリッシュにしたことも見られなかった。何かを見せたいという欲求も強いだろうが、そのような部分は加減なくスタイリッシュに修正しておいた。 講師様が間違いや「言ったら良かったのに」という部分では画面が灰色に変わりながら音声だけ出てくる区間がある。講師様もいただいたりもしたり、とにかくこんなA/S映像もまるで編まれた脚本のように教育ツールで見事に役割を果たしておいた。 テストを買ったのに設計が付いてきた。 しかし、その設計はテストよりも高価でした。 こんなクレイジーな立派な講義に受講坪54個だけなのを見てきて受講坪初めて使ってみるww 内容、声、オーディオ、映像、分量。 +9,999人になっているネームド講義よりキム・ウグン講師の講義がはるかによかった。

    • xzxz70032590

      おお…

  • dfghcvb11님의 프로필 이미지
    dfghcvb11

    受講レビュー 5

    平均評価 5.0

    5

    100% 受講後に作成

    この講義は単なるテスト講義ではありません。 私はテストを作成するためのJUnit、Mockitoなどの使い方を学んで適用しています。 それから、単にテストツールを使用する方法を超えて、良いテストコード、よく作られたテストコードについて疑問があり、このレッスンを見つけました。 講師様の1編講義を楽しく見たので基本的に信頼度が高く、目次の内容も興味深く見えました。 講義をすべて受講し、後期を残します。この講義は単なるテスト講義ではなく、 良いアーキテクチャとOOPについて心配するのに役立つ非常に素晴らしい講義です。 テストをする目的が単純な回帰防止だった私にとって、 テストと設計は相補的な関係であり、既存のレイヤードアーキテクチャの問題と、 レイヤードアーキテクチャで作成するテストの制限点を教えてください。 自然に良いデザインに悩んでくれました。 問題点を理論だけにしてくれるのではなく、コードをリファクタリングする過程を通じて、より良い構造とテストコードの記述を提示します。 先日、Mockitoを初めて学び、Stubbingを使ったテストに感心していた私に、 Mocktioが必要としたテストを外部ライブラリなしで純粋なJavaでテストする素晴らしい経験を与えました。 結局、すべてはOOPという1本の言葉がそのまま続く良い講義です。 それ以外にも、テストに必要な概念と講師の個人的な悩みが込められた意見を話していただくのも良かったです。開発分野に対する誠実さと態度を間接的に感じることができ、たくさん学びました。 良い講義ありがとうございます。

    • saechimdaeki님의 프로필 이미지
      saechimdaeki

      受講レビュー 48

      平均評価 5.0

      5

      100% 受講後に作成

      とても楽しく見て、私も新入社員たちが私たちはテストコードがないのですか?

      • 33cks14231753님의 프로필 이미지
        33cks14231753

        受講レビュー 4

        平均評価 5.0

        5

        100% 受講後に作成

        最後に、スプリングを勉強し、テストを書くためのコードを見ると、何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何度も何かを見ていました。 それで、なぜこのような反復的なテストを書くのか疑問に思いました。最後に、インフラストラクチャで新しい講義で、なぜSpring Test Developerが書くのに失敗するのかという新しいレッスンを見ました。 ちょうど私のための講義だ!して大胆に決済をしました。 頑強をした後、やはり後悔のない選択をしたようです。 10分講義を一時停止を押して一つ一つ講師様が話している部分が何なのかクマが考えたようです。それで、講義時間は6時間ですが、60時間ほどのクオリティがあると感じました。 ソフトウェア工学について視野を広げてくれた講師に感謝します。

        • carrykim님의 프로필 이미지
          carrykim

          受講レビュー 6

          平均評価 4.3

          5

          48% 受講後に作成

          これまで受講評を残したことがないのですが、この講義はちゃんです。

          期間限定セール、あと8日日で終了

          ¥41,580

          30%

          ¥7,494

          kok202の他の講座

          知識共有者の他の講座を見てみましょう!

          似ている講座

          同じ分野の他の講座を見てみましょう!