Java/Spring 주니어 개발자를 위한 오답노트
김우근
스프링이랑 JPA를 조금 다룰 줄 알게 된 당신, 앞으로 성장하기 위해 무엇을 어떻게 공부해야 할까요? 혹시 설계 공부를 해보겠다고 디자인 패턴을 공부하면서 패턴들을 무작정 암기하고 계시진 않으신가요? 제가 도와드릴게요!
초급
Java, Spring, 객체지향
BEST
Ghi chú lỗi của các nhà phát triển muốn thêm thử nghiệm Java/Spring
Chúng tôi sẽ hướng dẫn bạn cách thêm thử nghiệm vào Spring! Hơn nữa, bạn sẽ học cách thay đổi thiết kế Spring để có thể thực hiện thử nghiệm tự nhiên.
Đánh giá từ những học viên đầu tiên
Dịch cái này sang tiếng Việt
Spring cách thêm test
Kiến thức cần thiết cho bài kiểm tra
Làm thế nào để thực hiện một thử nghiệm tự nhiên
Mockito không có cách nào để kiểm tra
Tùy thuộc và khả năng kiểm tra
Kiến trúc và thiết kế lục giác (Hexagonal Architecture)
Phát triển thiết kế dự án
Hãy để tôi giải thích bản chất của bài kiểm tra!
Bắt đầu bằng cách thêm bài kiểm tra vào Spring và kết thúc bằng bài giảng về kiến trúc!
Bởi vì tôi nghĩ rằng để đưa ra cho bạn ý kiến đúng đắn về việc thử nghiệm, cuối cùng thì nó phải kết thúc bằng kiến trúc.
Tìm hiểu các khái niệm cơ bản về thử nghiệm và cách triển khai thử nghiệm trong Spring. Hơn nữa, bạn sẽ học cách thay đổi thiết kế Spring để cho phép thử nghiệm tự nhiên.
Vậy, đây là những gì chúng ta học được.
Bài kiểm tra
Tại sao lại cần đến nó?
Về bài kiểm tra
Các khái niệm cơ bản
Vào mùa xuân
Tiến hành thử nghiệm
phương pháp
Thiết kế mùa xuân
Tiến hóa
phương pháp
Lau dọn
Ngành kiến trúc
Lục giác
Ngành kiến trúc
Nhưng bạn đã bao giờ nghĩ tới điều này chưa?
Mối quan tâm và hiểu lầm về việc thử nghiệm
“Tôi thực sự muốn thử nghiệm. Tuy nhiên..."
Những người bạn làm việc tại các công ty khác đang từng bước phát triển bằng cách liên tục bổ sung các bài kiểm tra để theo kịp nhu cầu của thời đại. Nhưng công ty chúng tôi không bao gồm các bài kiểm tra. Tôi không muốn bị tụt hậu. Tôi cũng có ý chí học tập. Nhưng tôi không thể tìm ra cách đưa mã kiểm tra vào hệ thống cũ này .
“Tôi rất hào hứng khi thử nghiệm với H2.”
Kiểm tra bằng H2 quá chậm và phụ thuộc quá nhiều vào DB. Tất cả các thử nghiệm đều sử dụng H2. Việc chạy thử nghiệm rất tốn kém và vì các thử nghiệm chia sẻ h2 nên dữ liệu bị rối, do đó đôi khi thử nghiệm thành công nhưng đôi khi lại thất bại .
“Tôi không cảm thấy cần phải thử nghiệm.”
Nhóm của chúng tôi không có nhiều người và chúng tôi chưa bao giờ cảm thấy lo lắng đến vậy khi triển khai. Yêu cầu thay đổi tùy từng thời điểm. Nhưng làm thế nào để thực hiện TDD? Tôi nghĩ việc thử nghiệm chỉ làm chậm quá trình phát triển .
Kiểm tra, tôi cũng có cùng mối quan tâm.
Nếu bạn xem các cuốn sách hoặc hội thảo liên quan đến thử nghiệm trên thị trường, hầu hết chúng chỉ nói về những lợi ích của thử nghiệm, cách viết mã thử nghiệm, JUnit, Mockito và thế là hết. Các ví dụ đủ đơn giản để phù hợp với sở thích của người mới bắt đầu. Vì vậy, khi tôi cuối cùng cũng đọc đến cuối và đóng cuốn sách lại, tôi tự nhủ,
- "Làm sao anh có thể sử dụng thứ này ngoài thực địa?"
- "Làm thế nào để thêm bài kiểm tra vào Spring?"
- "Đây là bài kiểm tra được đưa ra khi không có khuôn khổ, vậy thì đưa vào có dễ không?"
Thật là khó hiểu. Kiểm thử JPA với H2... nghe có vẻ tuyệt. Nhưng làm sao tôi có thể kiểm tra nếu tôi không có cơ sở dữ liệu kiểm tra như ElasticSearch hoặc Cassandra? Ngoài ra, các thử nghiệm sử dụng H2 cũng cực kỳ chậm. Thật là phiền phức khi phải xoay nó nhiều lần trong ngày. Các bài kiểm tra thường xuyên bị lỗi và vào những ngày bảng DB bị thay đổi, tất cả các bài kiểm tra liên quan cũng phải được sửa đổi, điều này thường gây lãng phí thời gian.
Nếu bạn muốn học TDD, bạn không nên bắt đầu với TDD.
Sau đó, mọi lo lắng của tôi đã được giải quyết khi tôi bắt đầu học kiến trúc và DDD . Tôi biết. TDD luôn hấp dẫn. Nhưng TDD thực sự là một phương pháp hấp dẫn nhưng khó khăn. Nếu một tổ chức chưa từng áp dụng TDD trước đây cố gắng phát triển bằng TDD khi TDD đã trở nên phổ biến thì liệu có ổn không? TDD thực sự đòi hỏi nhiều kiến thức ban đầu và sự đồng thuận hơn bạn nghĩ.
Vì vậy, nếu bạn muốn học TDD, bạn không nên bắt đầu với TDD. Bạn nên học cho bài kiểm tra trước. Giống như bạn cần biết cách xử lý các phương trình để tính toán vậy.
Hãy để tôi kể cho bạn câu chuyện của tôi về việc thử nghiệm!
Mối quan tâm về thử nghiệm
Tôi sẽ giải quyết rõ ràng cho bạn.
Nếu bạn không cảm thấy cần phải thử nghiệm
Nếu bạn không cảm thấy cần phải thử nghiệm thì có lẽ dự án của bạn chưa lớn hoặc bạn có khả năng phát triển và văn hóa đủ tốt để không cần thử nghiệm. Bài kiểm tra không chính xác! Nhiều dự án lớn đã được phát triển ngay cả trước khi có thử nghiệm. Kiểm thử là công cụ để tạo ra phần mềm tốt chứ không phải là mục đích cuối cùng.
Nếu bạn không biết cách để có được thiết kế tốt thông qua thử nghiệm,
Có vẻ như bạn tập trung quá nhiều vào việc học cách làm bài kiểm tra . Nghiên cứu cách sử dụng JUnit, cách sử dụng Mockito và cách tích hợp h2 chắc chắn là nghiên cứu có ý nghĩa, nhưng đó không phải là bản chất của thử nghiệm. Bạn cần tìm hiểu lý do tại sao bạn nên làm bài kiểm tra, mục tiêu của bạn là gì và cách luyện tập để đạt được những mục tiêu đó.
Nếu bạn không biết cách kiểm tra mà không có khuôn khổ kiểm tra,
Câu hỏi về khuôn khổ thử nghiệm cũng có câu trả lời giống như câu hỏi trước. Nếu bạn đang ở trong môi trường sử dụng Typescript + Nest.js , bạn sẽ kiểm tra nó như thế nào? Bạn nên học cách kiểm thử mà không cần sử dụng khuôn khổ kiểm thử như Mockito hoặc H2 .
Một điều cần phải có cho các nhà phát triển Spring
Bạn cần phải học cách làm bài kiểm tra .
- ✅ Chúng tôi sẽ không dạy bạn cách tạo các bài kiểm tra không liên quan đến thực hành thực tế.
- ✅ Chúng tôi sẽ hướng dẫn bạn cách thêm các bài kiểm tra theo yêu cầu của nhà phát triển Spring.
- ✅ Đồng thời, chúng tôi sẽ cho bạn biết lý do tại sao bạn nên làm theo cách này .
Kiến thức dựa trên nguyên tắc này cũng có thể áp dụng cho các khuôn khổ khác. Cho dù bạn đang sử dụng Nest.js, Swing UI hay Gin... Tôi nghĩ kiến thức này có thể áp dụng ở bất cứ đâu.
Chương cuối cùng dẫn tới bài giảng về thiết kế . Bởi vì tôi cảm thấy rằng để giải thích đầy đủ giá trị của việc thử nghiệm, chúng ta không nên bỏ qua các cân nhắc về thiết kế.
Ít nhất, theo những gì tôi tìm kiếm, tôi không nghĩ mình tìm thấy bất kỳ cuốn sách hay bài giảng nào hướng dẫn cách thêm bài kiểm tra vào mùa xuân ở Hàn Quốc. Mọi người đều sử dụng các chú thích như @Mock và @Spy để mô phỏng và đưa các phụ thuộc vào để viết các bài kiểm tra. Nhưng làm sao bạn có thể kiểm tra nếu không có thư viện giả nào như vậy? Về cơ bản, bạn cần biết cách thử nghiệm mà không cần những chú thích này ! Và bạn cần có khả năng phân biệt được những gì bạn cần kiểm tra.
Thêm các bài kiểm tra dưới dạng bài kiểm tra
Tôi sẽ chỉ cho bạn cách làm!
Bạn sẽ học được nhu cầu thử nghiệm .
Tìm hiểu cách thêm các bài kiểm tra vào Spring mà không cần framework .
Bạn sẽ khám phá ra cách tốt hơn để sử dụng Spring .
Bạn sẽ hiểu cách chuyển đổi từ kiến trúc nhiều lớp sang kiến trúc lục giác .
Định hướng
Chúng tôi tìm hiểu lý do tại sao các tổ chức muốn bổ sung bài kiểm tra lại không áp dụng TDD. Thông thường, TDD mà tôi thực hiện bao gồm việc tìm hiểu lý do tại sao một cái gì đó lại không hoạt động. Hãy cùng xem xét các vấn đề phát sinh khi bạn bắt đầu thêm bài kiểm tra mà không hiểu rõ về bài kiểm tra.
Lý thuyết kiểm tra
Nghiên cứu kiến thức kiểm tra cơ bản. Thấu hiểu nhu cầu thử nghiệm và hiểu mối quan hệ giữa thử nghiệm và thiết kế. Hiểu được mối quan tâm của các nhà phát triển khi tạo bài kiểm tra. Cuối cùng, chúng ta hãy xem xét công việc cần làm để tăng khả năng kiểm tra cho thử nghiệm tự nhiên.
Phần 1 - Áp dụng thử nghiệm dựa trên dự án đồ chơi
Hãy cùng xem một dự án đồ chơi mà chúng ta sẽ sử dụng trong tương lai. Và chúng tôi cố gắng đạt được phạm vi bao phủ 100% bằng cách thêm càng nhiều bài kiểm tra càng tốt vào dự án đồ chơi. Trong quá trình này, các thư viện bên ngoài như h2, MockMvc và PowerMock được sử dụng.
Hãy cùng xem xét các bài kiểm tra cuối cùng đã được tạo ra và xem có vấn đề gì với các bài kiểm tra chỉ bao gồm lỗi hồi quy.
Khám phá theo hướng
Hãy cùng xem tại sao việc thêm bài kiểm tra vào dự án đồ chơi của chúng ta có thể không phải là một ý tưởng hay. Chúng ta cũng sẽ xem xét các vấn đề với kiến trúc phân lớp truyền thống. Và chúng tôi lắng nghe ý kiến của giảng viên về cách cải thiện nó.
Nếu bạn gặp khó khăn khi chỉ thêm các bài kiểm tra trong Phần 1, thì trong Phần 2, bạn sẽ học cách mô phỏng tự nhiên mà không cần thư viện bên ngoài như Mockito. Chúng ta hãy cùng xem cách thay đổi mã trước cho bài kiểm tra thực hành Phần 2.
Phần 2 - Cải thiện thiết kế cấu trúc dự án đồ chơi
Chúng tôi áp dụng những hiểu biết thu được từ quá trình khám phá hướng đi trước đó vào dự án đồ chơi của mình. Trong quá trình này, chúng tôi cải thiện thiết kế bằng cách thực hiện những thay đổi về cấu trúc. Và trong quá trình này, các kỹ thuật sau đây được sử dụng.
- Cấu trúc gói được cải thiện
- Phân biệt giữa đối tượng miền và đối tượng liên tục
- Đưa logic dịch vụ vào miền
- Đảo ngược sự phụ thuộc cho các liên kết bên ngoài
- Biến các bài kiểm tra thành các bài kiểm tra nhỏ
Kiến trúc phát triển
Hãy cùng khám phá cách phát triển kiến trúc của bạn thông qua mối tương quan giữa thử nghiệm và thiết kế. Hãy cùng xem kiến trúc phân lớp phát triển thành kiến trúc lục giác như thế nào. Việc tách biệt các mối quan tâm giúp các nhà phát triển tập trung vào lĩnh vực của họ.
Phát triển như một nhà phát triển
Tôi muốn giúp bạn!
Xin chào, tôi là Woogeun Kim ! 👋
Hiện tại tôi đang làm việc tại Kakao, và vì tôi thích sáng tạo nên tôi luôn phát triển một thứ gì đó sau giờ làm việc. Có câu nói: "Người lùn đứng trên vai người khổng lồ". Tôi cũng chỉ là một chú lùn nhỏ bé, nhưng tôi cố gắng truyền đạt kiến thức của mình để có thể giúp những người khổng lồ đã leo lên đó phát triển. Tôi có kinh nghiệm hướng dẫn nhiều lập trình viên mới vào nghề, vì vậy tôi có thể giúp bạn phát triển.
- ✅ Github / Blog
- ✅ Kỹ sư Backend Kakao hiện tại
- ✅ Giải Vàng hạng mục Chung cuộc thi Nhà phát triển SW mở rộng năm 2020: Giải thưởng của Cơ quan xúc tiến công nghiệp CNTT quốc gia
- ✅ Bài giảng Inflearn Ghi chú lỗi của nhà phát triển Java/Spring junior
Hỏi & Đáp 💬
H. Bạn có thể cho tôi biết cách sử dụng JUnit hoặc Mockito không?
Vâng, thật không may là khóa học không đề cập đến cách sử dụng JUnit và Mockito. Lý do như sau:
(Bối cảnh) Mỗi học sinh có một hoàn cảnh khác nhau. Nếu ai đó đã viết một vài bài kiểm tra, trình độ sử dụng thư viện của họ có thể khác nhau. Thư viện mà công ty sử dụng có thể không phải là JUnit hoặc Mockito. Có thể có những giao diện không được cung cấp vì các phiên bản khác nhau. Một ví dụ điển hình là JUnit4 không hỗ trợ @ParameterizedTest. Bên cạnh đó, việc sử dụng các thư viện nêu trên không quá khó khăn và đã có rất nhiều tài liệu liên quan hữu ích. Tôi nghĩ bạn có thể học cách sử dụng nó chỉ bằng cách đọc tệp Github README hoặc hướng dẫn chính thức. Vì vậy, tôi cho rằng cách sử dụng không quan trọng.
Học cách kiểm tra bằng một tính năng cụ thể do một thư viện cụ thể cung cấp có nghĩa là bạn không thể thực hiện kiểm tra đó nếu không có thư viện đó. Cách bạn thiết kế các bài kiểm tra và biến chúng thành các cấu trúc có thể kiểm tra được quan trọng hơn các công cụ hoặc khuôn khổ. Vì vậy, bài giảng này không tập trung vào các công cụ. Kiểm thử là một phần của quá trình phát triển. Do đó, tôi nghĩ rằng điều quan trọng hơn là phải kiểm tra các điểm cần được xem xét trong bối cảnh phân tích yêu cầu, thiết kế và triển khai cũng như bảo trì.
H. Có gì khác biệt so với các bài giảng trước ?
Như bạn có thể thấy từ chương trình giảng dạy, có một số nội dung trùng lặp với các bài giảng trước. Vì sẽ không thuyết phục và khó giải thích chi tiết những gì cần làm, nên tôi đã xây dựng bài giảng sao cho bạn có thể tự học bài giảng có liên quan. Vì vậy, hãy nhớ kiểm tra mục lục và xem có nội dung nào trùng lặp không.
Thành thật mà nói, nếu bạn đã hiểu đúng các bài giảng trước, tôi không nghĩ bạn cần phải học lại bài giảng này. Nếu bài giảng trước là bài giảng giải thích lý do tại sao về mặt cấu trúc, bạn có thể coi bài giảng này là bài giảng giải quyết cách giải quyết thực sự ở cấp độ mã.
H. Tôi cần biết điều gì trước khi tham gia khóa học không?
Bài giảng này không dạy về Spring hoặc JPA. Bài giảng được tiến hành với giả định rằng sinh viên có thể sử dụng Spring và JPA nói chung. Ngoài ra, chúng tôi sẽ chỉ cho bạn cách thêm các bài kiểm tra vào Spring , nhưng về cơ bản, chúng tôi tập trung vào cách giải quyết các vấn đề phụ thuộc và tôi không nghĩ rằng nó nhất thiết chỉ giới hạn ở một ngôn ngữ hoặc khuôn khổ nào đó. Ngoài ra, không cần có kiến thức chuyên môn nào cả :)
💾 Vui lòng kiểm tra trước khi tham gia lớp học!
- Nội dung thực hành trong bài giảng được thiết kế sao cho độc lập nhất có thể với các thư viện, IDE hoặc thông số kỹ thuật cụ thể. Tôi đã cố gắng tránh tạo ra các bài giảng tận dụng các tính năng cụ thể có trong các phiên bản cụ thể. Trong trường hợp cần thiết, tôi muốn thông báo với bạn rằng cấu hình máy tính xách tay của giảng viên như sau.
- Thông số kỹ thuật PC và hệ điều hành: MacBook Pro (16 inch, 2019) và 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
- Chúng tôi cung cấp cho học sinh 12 tài liệu PPT, mỗi tài liệu dài khoảng 40 trang.
- Khóa học này không đề cập đến ngôn ngữ lập trình hoặc cách xử lý Spring.
- Giải thích này dựa trên sự hiểu biết của những người dùng đã từng làm việc với Spring và Spring Data JPA ít nhất một lần.
- Tôi sẽ giải thích với giả định là bạn biết về Controller, Service và Repository.
- Tôi đã phát hành bài học xem trước về dự án đồ chơi sẽ được sử dụng trong bài giảng. Nếu bạn có thể kiểm tra và hiểu được thì không sao cả.
- Được phép chụp một phần PPT và đăng nội dung đã nghiên cứu lên blog, nhưng không được phép chia sẻ toàn bộ tài liệu trên blog cá nhân. Cảm ơn sự hiểu biết của bạn!
- Có một số nội dung trùng lặp với các bài giảng trước. Vui lòng kiểm tra mục lục và xem có nội dung nào trùng lặp không.
- Vui lòng xem dự án demo tại đây .
Khuyến nghị cho
những người này
Khóa học này dành cho ai?
Spring muốn thêm thử nghiệm
Spring không biết phải thêm thử nghiệm như thế nào
내가 개발한 Spring dự án có cấu trúc thiết kế đúng không?
Những người đã cố gắng làm bài kiểm tra nhưng không thành công
H2 như DB thử nghiệm không có trong NoSQL và bạn muốn thêm thử nghiệm vào
Cần biết trước khi bắt đầu?
Java code hiểu được
Spring cơ bản (Những ai biết Controller / Service / Repository là gì)
Bạn đã từng sử dụng JPA chưa?
3,466
Học viên
250
Đánh giá
47
Trả lời
4.9
Xếp hạng
2
Các khóa học
- (현) 카카오 백엔드 엔지니어
- (수상) 🏆 공개 SW 개발자 대회 [2020 일반부문 / 금상_정보통신산업진흥원장상]
현재 카카오에서 일하고 있고, 만드는 것을 좋아해서, 퇴근 후에도 항상 무언가를 개발하고 있습니다.
"거인의 어깨 위에 선 난쟁이"라는 말이 있습니다. 저 역시 한낱 작은 난쟁이일 뿐이지만, 올라탄 거인의 성장에 도움이 될 수 있도록 지식의 대물림을 위해 노력하고 있습니다. 다수의 주니어 개발자분들을 멘토링 한 경험이 있어서 여러분의 성장을 도와줄 수 있을 거예요.
깃허브 > https://github.com/kok202
블로그 > https://kok202.tistory.com
Chương trình giảng dạy
Tất cả
25 bài giảng ∙ (6giờ 20phút)
Tài liệu khóa học:
Tài liệu bài giảng
Ngày đăng:
Cập nhật lần cuối:
Đánh giá
Tất cả
174 đánh giá
4.9
174 đánh giá
- 크아아앙
Đánh giá 2
∙
Đánh giá trung bình 3.0
5
100% đã tham gia내가 인프런에서 결제한 모든 강의 통틀어서 최고의 강의라 단언한다. 책에서 베끼지 않고 머리 쥐어 뜯으며 만든 오리지널 커리큘럼 구성, 강의 마다 꽉꽉 차 있는 알맹이들, 어영부영 횡설수설 없음, 깔끔한 멘트와 문장, 적절한 속도와 명확한 발화, 테스트라는 구체화된 실천 방법을 통해 설계라는 큰 그림을 그리고, 다시 설계라는 바탕 아래 테스트를 끌어낸다. 강사님이 얼마나 고민하고 반복하고 개선하며 개발을 해오셨는지 보이지 않아도 보인다. 그걸 강의로 기가 막히게 녹여 내셨다. 인프런에서 강의 한 두개 들어본 게 아니지만 이 강의 만큼 A/S를 세련되게 한 것도 못봤다. 영상이라는 게 또 찍고나면 글처럼 쉽게 수정할 수 있는게 아니기도 하고, 강의 특성 상 항상 아름답고 한치의 실수도 없는 뭔가를 보여주고 싶은 욕구도 강할텐데 그러한 부분은 가감없이 세련되게 수정해두었다. 강사님이 실수나 "이랬으면 좋았을텐데"하는 부분에서는 화면이 회색으로 바뀌면서 음성만 나오는 구간이 있다. 이런 부분이 나오면 내가 정신차리고 듣고 있나 점검도 되고, 내 생각과 비교해 볼 수도 있고, 저런 고민을 강사님도 하시는 구나 싶기도 하고, 암튼 이런 A/S영상도 마치 짜여진 각본처럼 교육 도구로 훌륭히 역할을 하게 해두었다. 테스트를 샀는데 설계가 딸려왔다. 근데 그 설계가 테스트보다 더 비싼거였다. 이런 미친듯이 훌륭한 강의에 수강평 54개 뿐인 거 보고 빡쳐서 수강평 처음 써 본다 ㅋㅋ 내용, 목소리, 오디오, 영상, 분량.. 모든 게 응집력있게 뭉쳐 있어서 마치 아름다운 설계를 보는 것 같았다. 나는 개인적으로 수강생 +9,999명 되어 있는 네임드 강의보다 김우근 강사님의 강의가 훨씬 좋았다.
오오오...
dfghcvb11Đánh giá 5
∙
Đánh giá trung bình 5.0
5
100% đã tham gia이 강의는 단순한 테스트 강의가 아닙니다. 저는 테스트를 작성하기 위한 JUnit, Mockito 등의 사용법을 배우고 적용해 나가는 중이였습니다. 그러다가 단순히 테스트 도구를 사용하는 방법을 넘어, 좋은 테스트 코드, 잘 만든 테스트 코드에 대해 궁금증이 생겼고, 이 강의를 발견했습니다. 강사님의 1편 강의를 재밌게 본 터라 기본적으로 신뢰도가 높았고, 목차의 내용도 흥미로워 보였습니다. 강의를 전부 수강하고 후기를 남깁니다. 이 강의는 단순한 테스트 강의가 아닌, 좋은 아키텍처와 OOP에 대해 고민할 수 있게 도와주는 아주 멋진 강의입니다. 테스트를 짜는 목적이 단순한 회귀 방지였던 저에게, 테스트와 설계는 상호 보완적 관계이며, 기존 레이어드 아키텍처의 문제점과, 레이어드 아키텍처에서 작성하는 테스트의 한계점을 알려 주면서 자연스럽게 좋은 설계에 대해 고민하게 만들어 주었습니다. 문제점들을 이론으로만 짚어주는게 아니라, 코드를 리팩토링 하는 과정을 통해 더 나은 구조와 테스트 코드 작성을 제시해줍니다. 얼마전 Mockito를 처음 배우고, Stubbing을 이용한 테스트에 감탄하고 있던 저에게, Mocktio가 필요했던 테스트들을 외부 라이브러리 없이 순수 자바로 테스트하는 멋진 경험을 선사해 주었습니다. 결국 모든 것은 OOP라는 1편의 말씀이 그대로 이어지는 좋은 강의입니다. 그 외에도 테스트에 필요한 개념들과 강사님의 개인적인 고민이 담긴 의견들을 이야기 해주시는 것도 좋았습니다. 개발 분야에 대한 진중함과 태도들을 간접적으로 느낄 수 있어 많이 배웠습니다. 좋은 강의 감사합니다.
- saechimdaeki
Đánh giá 48
∙
Đánh giá trung bình 5.0
- chan park
Đánh giá 4
∙
Đánh giá trung bình 5.0
5
100% đã tham gia마침 스프링을 공부하고 테스트를 어떻게 작성하는 코드들이 보니 반복되는 의미없는 테스트 작성들이 눈에 보였습니다. 그래서 왜 이런 반복적인 테스트를 작성하는지 의문점이 들었습니다. 그런데 마침 인프런에서 새 강의로 왜 스프링 테스트 개발자들이 작성하는데 실패하는지 라는 강의가 새로 나온걸 보았습니다. 딱 저를 위한 강의다! 해서 과감히 결제를 하였습니다. 완강을 한 후, 역시 후회없는 선택을 한 것 같습니다. 10분 강의를 일시정지를 눌러 하나하나 강사님께서 이야기 하시는 부분이 무엇인지 곰곰이 생각한 것 같습니다. 그래서 강의 시간은 6시간이지만 60시간 만큼의 퀄리티가 있다는 게 느껴졌습니다. 소프트웨어 공학에 대해 시야를 넓혀준 강사님께 감사드립니다.
- 김선진
Đánh giá 4
∙
Đánh giá trung bình 5.0
Ưu đãi có thời hạn
44.550 ₫
25%
1.255.366 ₫
Khóa học khác của kok202
Hãy khám phá các khóa học khác của giảng viên!
Khóa học tương tự
Khám phá các khóa học khác trong cùng lĩnh vực!
![따라하며 배우는 리액트 테스트 [2023.11 업데이트]강의 썸네일](https://cdn.inflearn.com/public/courses/327775/cover/0ef9c174-9974-4530-9470-d1ce8648aa75/327775-eng.png?f=avif&w=420)
![[JSP부터 스프링부트까지]포기없는 SpringBoot로 가는길강의 썸네일](https://cdn.inflearn.com/public/files/courses/334897/cover/01k2j21p3rz09cqh5s0frefaa5?f=avif&w=420)
![[DevOps 정석 1] Monolith to Microservice 전환 with Spring/Python/Node.js와 Strangler Fig 패턴강의 썸네일](https://cdn.inflearn.com/public/courses/329980/cover/7687ff1a-6346-4e04-b2be-ceac51d6a1cc/329980-eng.jpg?f=avif&w=420)
