강의

멘토링

로드맵

Inflearn brand logo image
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,423

受講生

246

受講レビュー

47

回答

4.9

講座評価

2

講座

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

 

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

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

 

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

カリキュラム

全体

25件 ∙ (6時間 20分)

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

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

受講レビュー

全体

170件

4.9

170件の受講レビュー

  • 크아아앙님의 프로필 이미지
    크아아앙

    受講レビュー 2

    平均評価 3.0

    5

    100% 受講後に作成

    내가 인프런에서 결제한 모든 강의 통틀어서 최고의 강의라 단언한다. 책에서 베끼지 않고 머리 쥐어 뜯으며 만든 오리지널 커리큘럼 구성, 강의 마다 꽉꽉 차 있는 알맹이들, 어영부영 횡설수설 없음, 깔끔한 멘트와 문장, 적절한 속도와 명확한 발화, 테스트라는 구체화된 실천 방법을 통해 설계라는 큰 그림을 그리고, 다시 설계라는 바탕 아래 테스트를 끌어낸다. 강사님이 얼마나 고민하고 반복하고 개선하며 개발을 해오셨는지 보이지 않아도 보인다. 그걸 강의로 기가 막히게 녹여 내셨다. 인프런에서 강의 한 두개 들어본 게 아니지만 이 강의 만큼 A/S를 세련되게 한 것도 못봤다. 영상이라는 게 또 찍고나면 글처럼 쉽게 수정할 수 있는게 아니기도 하고, 강의 특성 상 항상 아름답고 한치의 실수도 없는 뭔가를 보여주고 싶은 욕구도 강할텐데 그러한 부분은 가감없이 세련되게 수정해두었다. 강사님이 실수나 "이랬으면 좋았을텐데"하는 부분에서는 화면이 회색으로 바뀌면서 음성만 나오는 구간이 있다. 이런 부분이 나오면 내가 정신차리고 듣고 있나 점검도 되고, 내 생각과 비교해 볼 수도 있고, 저런 고민을 강사님도 하시는 구나 싶기도 하고, 암튼 이런 A/S영상도 마치 짜여진 각본처럼 교육 도구로 훌륭히 역할을 하게 해두었다. 테스트를 샀는데 설계가 딸려왔다. 근데 그 설계가 테스트보다 더 비싼거였다. 이런 미친듯이 훌륭한 강의에 수강평 54개 뿐인 거 보고 빡쳐서 수강평 처음 써 본다 ㅋㅋ 내용, 목소리, 오디오, 영상, 분량.. 모든 게 응집력있게 뭉쳐 있어서 마치 아름다운 설계를 보는 것 같았다. 나는 개인적으로 수강생 +9,999명 되어 있는 네임드 강의보다 김우근 강사님의 강의가 훨씬 좋았다.

    • 안아줘요

      오오오...

  • dfghcvb11님의 프로필 이미지
    dfghcvb11

    受講レビュー 5

    平均評価 5.0

    5

    100% 受講後に作成

    이 강의는 단순한 테스트 강의가 아닙니다. 저는 테스트를 작성하기 위한 JUnit, Mockito 등의 사용법을 배우고 적용해 나가는 중이였습니다. 그러다가 단순히 테스트 도구를 사용하는 방법을 넘어, 좋은 테스트 코드, 잘 만든 테스트 코드에 대해 궁금증이 생겼고, 이 강의를 발견했습니다. 강사님의 1편 강의를 재밌게 본 터라 기본적으로 신뢰도가 높았고, 목차의 내용도 흥미로워 보였습니다. 강의를 전부 수강하고 후기를 남깁니다. 이 강의는 단순한 테스트 강의가 아닌, 좋은 아키텍처와 OOP에 대해 고민할 수 있게 도와주는 아주 멋진 강의입니다. 테스트를 짜는 목적이 단순한 회귀 방지였던 저에게, 테스트와 설계는 상호 보완적 관계이며, 기존 레이어드 아키텍처의 문제점과, 레이어드 아키텍처에서 작성하는 테스트의 한계점을 알려 주면서 자연스럽게 좋은 설계에 대해 고민하게 만들어 주었습니다. 문제점들을 이론으로만 짚어주는게 아니라, 코드를 리팩토링 하는 과정을 통해 더 나은 구조와 테스트 코드 작성을 제시해줍니다. 얼마전 Mockito를 처음 배우고, Stubbing을 이용한 테스트에 감탄하고 있던 저에게, Mocktio가 필요했던 테스트들을 외부 라이브러리 없이 순수 자바로 테스트하는 멋진 경험을 선사해 주었습니다. 결국 모든 것은 OOP라는 1편의 말씀이 그대로 이어지는 좋은 강의입니다. 그 외에도 테스트에 필요한 개념들과 강사님의 개인적인 고민이 담긴 의견들을 이야기 해주시는 것도 좋았습니다. 개발 분야에 대한 진중함과 태도들을 간접적으로 느낄 수 있어 많이 배웠습니다. 좋은 강의 감사합니다.

    • saechimdaeki님의 프로필 이미지
      saechimdaeki

      受講レビュー 48

      平均評価 5.0

      5

      100% 受講後に作成

      너무 재미있게 보았고 저도 신입분들이 저희는 테스트 코드가 없나요? 라고 물을 때 반성하게 될 것 같네요 ㅠ_ㅠ.

      • chan park님의 프로필 이미지
        chan park

        受講レビュー 4

        平均評価 5.0

        5

        100% 受講後に作成

        마침 스프링을 공부하고 테스트를 어떻게 작성하는 코드들이 보니 반복되는 의미없는 테스트 작성들이 눈에 보였습니다. 그래서 왜 이런 반복적인 테스트를 작성하는지 의문점이 들었습니다. 그런데 마침 인프런에서 새 강의로 왜 스프링 테스트 개발자들이 작성하는데 실패하는지 라는 강의가 새로 나온걸 보았습니다. 딱 저를 위한 강의다! 해서 과감히 결제를 하였습니다. 완강을 한 후, 역시 후회없는 선택을 한 것 같습니다. 10분 강의를 일시정지를 눌러 하나하나 강사님께서 이야기 하시는 부분이 무엇인지 곰곰이 생각한 것 같습니다. 그래서 강의 시간은 6시간이지만 60시간 만큼의 퀄리티가 있다는 게 느껴졌습니다. 소프트웨어 공학에 대해 시야를 넓혀준 강사님께 감사드립니다.

        • 김선진님의 프로필 이미지
          김선진

          受講レビュー 4

          平均評価 5.0

          5

          48% 受講後に作成

          지금까지 수강평을 남겨본 적 없는데 이 강의는 짱입니다.

          ¥7,028

          kok202の他の講座

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

          似ている講座

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