
Java/Spring 주니어 개발자를 위한 오답노트
김우근
스프링이랑 JPA를 조금 다룰 줄 알게 된 당신, 앞으로 성장하기 위해 무엇을 어떻게 공부해야 할까요? 혹시 설계 공부를 해보겠다고 디자인 패턴을 공부하면서 패턴들을 무작정 암기하고 계시진 않으신가요? 제가 도와드릴게요!
Basic
Java, Spring, 객체지향
Spring にテストを追加する方法を説明します。さらに、より自然なテストを行うために Spring の設計を変更する方法も学びます。
Spring にテストを追加する方法
テストに必要な概念
自然なテストを行う方法
Mockito なしでテストする方法
依存性とテスト可能性
ヘキサゴナル アーキテクチャ (Hexagonal Architecture) と設計
プロジェクト設計を進める
テストの本質をわかります!
テストに対する正しい意見を伝えるためには、結局アーキテクチャで終わらなければならないという考えをしたからです。
テストの基本的な概念を学び、Spring(スプリング)にテストを入れる方法を学びます。さらに、自然なテストができるようにスプリング設計を変更する方法を学びます。
テスト
必要な理由
テストについて
基本概念
Springへ
テストを入れる
方法
Springデザイン
進化させる
方法
クリーン
アーキテクチャ
ヘキサゴナル
アーキテクチャ
他の会社に通う友人は、時代のニーズに合わせてテストを着実に入れていきます。ところで、当社はテストを入れていません。遅れたくありません。勉強する意志もあります。ところで、とにかくこのレガシーシステムにテストコードをどのように入れなければならないか感がありません。
H2を使ったテストは遅すぎてDBに依存しすぎます。すべてのテストがH2を使用しています。テストを回すのは負担になり、テストがh2を共有しているので、データが混乱しているときはテストが成功し、またあるときは失敗します。
私たちのチームは、人がそれほど多くもなく、配布しながらもあまり不安を感じたことがありません。要件は時々変わります。しかし、TDDをどのようにしますか?テストは開発速度だけ遅れるだけだと思います。
市中に出ているテスト関連の本やセミナーを探してみると、ほとんどそのままテストの利点、テストコードの作り方、JUnit、Mockito程度だけ話して終わります。例はちょうど入門者の好みに合うほど簡単な例だけです。だから最後に行って本を覆う時はこんな気がします。
混乱しました。 H2を使ったJPAテスト...まあいいです。しかし、ElasticSearchやCassandraのようにテスト用のDBがない場合は、どのようにテストするのですか?さらに、H2を使ったテストは本当に致命的なほど遅かった。一日にも何度も回す負担でした。テストは頻繁に壊れてDBテーブルでも変更される日には関連するテストも芽生えて修正しなければならないので時間の無駄のようだと思います。
その間、私の悩みは、アーキテクチャとDDDの勉強を始めながら、すべて解決されます。知っています。 TDDは常にホットです。ところで、TDDは本当に魅力的でありながらも難しい方法論です。 TDDをやったことのない組織でTDDが流行っているので、これからTDDとして開発しようとすればそれになるのでしょうか? TDDは、思ったより始める前に知っておくべき選手の知識と共感を必要とします。
したがって、TDDを勉強するには、TDDから勉強しないでください。テストを最初に勉強する必要があります。微積分をするには、方程式から扱うと知っておく必要があるようです。
テストの必要性が感じられない場合は、まだプロジェクトの規模がそれほど大きくないか、テストがなくても十分な開発能力と文化を備えているようです。テストは正解ではありません!テストがなかった時代にも素晴らしいプロジェクトがたくさん開発されました。テストは良いソフトウェアを得るためのツールなので、それ自体が目標ではありません。
テストをする方法だけに重すぎて勉強していたようです。 JUnitの使い方、Mockitoの使い方、h2を連動する方法を勉強することは明らかに意味のある勉強ですが、それがテストの本質ではありません。なぜテストをしなければならず、どのような目標があり、その目標を達成するためにどのように実践するべきかを学ぶ必要があります
テストフレームワークに関する質問も以前の質問と同じ答えです。もしあなたがTypescript
+ Nest.js
を書く環境にいるなら、どうやってテストしますか? Mockito、H2などのテストフレームワークなしでテストする方法を学ぶ必要があります。
この原理に基づいた知識は、他のフレームワークでも一般的な知識です。 Nest.jsを使っていた、Swing UIを使っていた、Ginを使っていた…どこでも適用できる知識だと思います。
終章に行くと、設計に関する講義につながります。テストの価値を最大限に説明していただくためには設計についての内容が抜けてはいけないと考えたからです。
少なくとも私がブラウズ論国内のスプリングにテストを入れる方法を教えてくれる本や講義は見られないようです。すべて@Mock
、 @Spy
これらのアノテーションを利用してmockingと依存性注入を受けてテストを作成します。しかし、もしこのようなMockライブラリが存在しない環境なら、どのようにテストするのでしょうか?本質的に、これらのアノテーションがなくてもテストする方法を知る必要があります!そして、テストすべき対象が何であるかを区別できる必要があります。
テストの必要性がわかります。
フレームワークなしでスプリングにテストを入れる方法がわかります。
スプリングを使用するより良い方法がわかります。
レイヤードアーキテクチャからヘキサゴナルアーキテクチャへの移行方法を理解します。
オリエンテーション
テストを追加したい組織でTDDを導入するときに失敗する理由を見てください。一般的に、私がしているTDDはなぜ失敗するのかを見ています。テストを正しく理解することなく、テストをランダムに挿入し始めたときに発生する問題をまとめます。
テストの理論
基本的なテスト知識を勉強します。テストの必要性を共感し、テストと設計の相関関係を特定します。テストを作成しながら、開発者はどのような悩みをすべきかを理解します。最後に、自然なテストのためにTestabilityを向上させることについて説明します。
パート1 - トイプロジェクトベースのテストを適用
今後使用するトイプロジェクトを見てみましょう。そして、トイプロジェクトにうんざりしてテストを入れて、できるだけテストを入れてカバレッジ100%を達成してみます。このプロセスでは、h2、MockMvc、PowerMockなどの外部ライブラリを使用します。
最終的に作成されたテストを一緒に見て、回帰のバグだけをカバーするためのテストにはどのような問題があるかを見てください。
方向性ナビゲーション
私たちのトイプロジェクトにテストを入れたのがあまり良い方向ではない理由を一緒に見てみましょう。さらに、従来のレイヤードアーキテクチャの問題点についてまとめてみましょう。そしてどのように改善するか、講演者の意見を聞きます。
1部実機で無作為テストを入れるために苦労していたら、2部ではMockitoのような外部ライブラリなしで自然にMockする方法を身につけます。パート2の実践のために、事前にどのようにコードを変更するのかを見てみましょう。
パート2 - トイプロジェクト構造設計の改善
先進の方向性ナビゲーションを通じて得られたインサイトを当社のトイプロジェクトに導入します。この過程で構造的な変化を与え、設計を改善します。そしてこの過程で以下のような技法が使われます。
進化するアーキテクチャ
テストと設計の相関関係を介してアーキテクチャを進化させる方法について説明します。レイヤードアーキテクチャがヘキサゴナルアーキテクチャにどのように変わるかを見てください。関心を分離しながら、開発者がドメインに集中する方法を学びます。
現在カカオで働いていて、作るのが好きなので、退勤後も常に何かを開発しています。 「巨人の肩の上に立った小人」という言葉があります。私もやはり小さな小人だけですが、上がった巨人の成長に役立つように知識の対峙に努めています。多くのジュニア開発者の方々を指導した経験があり、皆様の成長をお手伝いできます。
Q. JUnitやMockitoの使い方は教えていただけませんか?
はい。理由は以下の通りです。
コンテキスト) 受講生の個人ごとにとどまる状況が異なります。すでに数回テストをした人がいる場合は、ライブラリを扱う熟練度が異なる場合があります。会社で使用しているライブラリがJUnitやMockitoではないかもしれない。バージョンが異なるため、提供しないインターフェイスが存在する可能性があります。代表的な例として、JUnit4は@ParameterizedTestをサポートしていません。さらに、前述のライブラリの使い方はそれほど難しくなく、関連する良い資料がすでに多すぎます。とにかく、Github READMEファイルを読んだり、公式ガイドを読んだりするだけで十分な使い方を学ぶことができると思います。したがって、使用法は重要な内容ではないと思いました。
テストデザイン) 特定のライブラリが提供する特定の機能を使ってテストする方法を学ぶことは、そのライブラリがなければそのテストを行うことができないということです。ツールやフレームワークよりテストをどのように設計し、どのようにテスト可能な構造に変えるかがより重要です。したがって、この講義はツールに集中しません。テストは開発プロセスの一部です。したがって、要件の分析、設計、配置、メンテナンスなどの文脈で考慮すべき点を確認することがより重要であると考えました。
Q. 以前の講義との違いは何がありますか?
カリキュラムを見ればわかりますが、以前の講義と重複する内容が多少あります。こうする必要があるということだけを説明するには説得力も不足して文脈を理解させてくれないので、独立して該当講義も受講できるよう講義を構成しました。だから必ず目次を確認してみて、重なる内容があるか確認してみてください。
率直な話で以前の講義をしっかり理解していたら、あえて重複して受講する必要はないと思います。以前のレッスンが構造的になぜこれを行うべきかを説明するレッスンであれば、今回のレッスンは実際にコードレベルでどのように解かれるかを扱うレッスンと見なすことができます。
Q. 受講前に知っておくべきことはありますか?
この講義は、スプリングやJPAを教えてくれる講義ではありません。受講者がおおよそのSpringとJPAに対処できることを前提に講義を行います。また、スプリングにテストを入れる方法をお知らせしていますが、本質的には依存性をどのように解放するかについて焦点を当てて進んでおり、必ずしも言語やフレームワークにこだわる内容ではないと思います。なお、専攻知識は必要ありません :)
💾受講前に確認してください!
学習対象は
誰でしょう?
Springにテストを入れたい方
Spring にテストをどのように入れるべきか分からない方
私が開発したSpringプロジェクトが正しい設計構造であるか混乱している人
テストを入れてみたけど失敗した方
H2のようなテストDBがないNoSQLにテストを入れたい方
前提知識、
必要でしょうか?
Java コードを理解できる方
Spring の基本 (Controller / Service / Repository について知っている方)
JPA を使用したことがある人
3,423
受講生
246
受講レビュー
47
回答
4.9
講座評価
2
講座
현재 카카오에서 일하고 있고, 만드는 것을 좋아해서, 퇴근 후에도 항상 무언가를 개발하고 있습니다.
"거인의 어깨 위에 선 난쟁이"라는 말이 있습니다. 저 역시 한낱 작은 난쟁이일 뿐이지만, 올라탄 거인의 성장에 도움이 될 수 있도록 지식의 대물림을 위해 노력하고 있습니다. 다수의 주니어 개발자분들을 멘토링 한 경험이 있어서 여러분의 성장을 도와줄 수 있을 거예요.
깃허브 > https://github.com/kok202
블로그 > https://kok202.tistory.com
全体
25件 ∙ (6時間 20分)
講座資料(こうぎしりょう):
3. テストの概要と開発者がすべき悩み
10:05
4. テストの必要性とテストの3分類
10:42
5. テストに必要な概念
09:13
6. 依存性とテスト性(1)
06:10
7. 依存性とテスト性(2)
10:35
8. 実技前の事前探索
13:00
全体
170件
4.9
170件の受講レビュー
受講レビュー 2
∙
平均評価 3.0
5
내가 인프런에서 결제한 모든 강의 통틀어서 최고의 강의라 단언한다. 책에서 베끼지 않고 머리 쥐어 뜯으며 만든 오리지널 커리큘럼 구성, 강의 마다 꽉꽉 차 있는 알맹이들, 어영부영 횡설수설 없음, 깔끔한 멘트와 문장, 적절한 속도와 명확한 발화, 테스트라는 구체화된 실천 방법을 통해 설계라는 큰 그림을 그리고, 다시 설계라는 바탕 아래 테스트를 끌어낸다. 강사님이 얼마나 고민하고 반복하고 개선하며 개발을 해오셨는지 보이지 않아도 보인다. 그걸 강의로 기가 막히게 녹여 내셨다. 인프런에서 강의 한 두개 들어본 게 아니지만 이 강의 만큼 A/S를 세련되게 한 것도 못봤다. 영상이라는 게 또 찍고나면 글처럼 쉽게 수정할 수 있는게 아니기도 하고, 강의 특성 상 항상 아름답고 한치의 실수도 없는 뭔가를 보여주고 싶은 욕구도 강할텐데 그러한 부분은 가감없이 세련되게 수정해두었다. 강사님이 실수나 "이랬으면 좋았을텐데"하는 부분에서는 화면이 회색으로 바뀌면서 음성만 나오는 구간이 있다. 이런 부분이 나오면 내가 정신차리고 듣고 있나 점검도 되고, 내 생각과 비교해 볼 수도 있고, 저런 고민을 강사님도 하시는 구나 싶기도 하고, 암튼 이런 A/S영상도 마치 짜여진 각본처럼 교육 도구로 훌륭히 역할을 하게 해두었다. 테스트를 샀는데 설계가 딸려왔다. 근데 그 설계가 테스트보다 더 비싼거였다. 이런 미친듯이 훌륭한 강의에 수강평 54개 뿐인 거 보고 빡쳐서 수강평 처음 써 본다 ㅋㅋ 내용, 목소리, 오디오, 영상, 분량.. 모든 게 응집력있게 뭉쳐 있어서 마치 아름다운 설계를 보는 것 같았다. 나는 개인적으로 수강생 +9,999명 되어 있는 네임드 강의보다 김우근 강사님의 강의가 훨씬 좋았다.
오오오...
受講レビュー 5
∙
平均評価 5.0
5
이 강의는 단순한 테스트 강의가 아닙니다. 저는 테스트를 작성하기 위한 JUnit, Mockito 등의 사용법을 배우고 적용해 나가는 중이였습니다. 그러다가 단순히 테스트 도구를 사용하는 방법을 넘어, 좋은 테스트 코드, 잘 만든 테스트 코드에 대해 궁금증이 생겼고, 이 강의를 발견했습니다. 강사님의 1편 강의를 재밌게 본 터라 기본적으로 신뢰도가 높았고, 목차의 내용도 흥미로워 보였습니다. 강의를 전부 수강하고 후기를 남깁니다. 이 강의는 단순한 테스트 강의가 아닌, 좋은 아키텍처와 OOP에 대해 고민할 수 있게 도와주는 아주 멋진 강의입니다. 테스트를 짜는 목적이 단순한 회귀 방지였던 저에게, 테스트와 설계는 상호 보완적 관계이며, 기존 레이어드 아키텍처의 문제점과, 레이어드 아키텍처에서 작성하는 테스트의 한계점을 알려 주면서 자연스럽게 좋은 설계에 대해 고민하게 만들어 주었습니다. 문제점들을 이론으로만 짚어주는게 아니라, 코드를 리팩토링 하는 과정을 통해 더 나은 구조와 테스트 코드 작성을 제시해줍니다. 얼마전 Mockito를 처음 배우고, Stubbing을 이용한 테스트에 감탄하고 있던 저에게, Mocktio가 필요했던 테스트들을 외부 라이브러리 없이 순수 자바로 테스트하는 멋진 경험을 선사해 주었습니다. 결국 모든 것은 OOP라는 1편의 말씀이 그대로 이어지는 좋은 강의입니다. 그 외에도 테스트에 필요한 개념들과 강사님의 개인적인 고민이 담긴 의견들을 이야기 해주시는 것도 좋았습니다. 개발 분야에 대한 진중함과 태도들을 간접적으로 느낄 수 있어 많이 배웠습니다. 좋은 강의 감사합니다.
受講レビュー 48
∙
平均評価 5.0
受講レビュー 4
∙
平均評価 5.0
5
마침 스프링을 공부하고 테스트를 어떻게 작성하는 코드들이 보니 반복되는 의미없는 테스트 작성들이 눈에 보였습니다. 그래서 왜 이런 반복적인 테스트를 작성하는지 의문점이 들었습니다. 그런데 마침 인프런에서 새 강의로 왜 스프링 테스트 개발자들이 작성하는데 실패하는지 라는 강의가 새로 나온걸 보았습니다. 딱 저를 위한 강의다! 해서 과감히 결제를 하였습니다. 완강을 한 후, 역시 후회없는 선택을 한 것 같습니다. 10분 강의를 일시정지를 눌러 하나하나 강사님께서 이야기 하시는 부분이 무엇인지 곰곰이 생각한 것 같습니다. 그래서 강의 시간은 6시간이지만 60시간 만큼의 퀄리티가 있다는 게 느껴졌습니다. 소프트웨어 공학에 대해 시야를 넓혀준 강사님께 감사드립니다.
受講レビュー 4
∙
平均評価 5.0
¥7,028
知識共有者の他の講座を見てみましょう!
同じ分野の他の講座を見てみましょう!