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.
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ì.
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.
Tôi chắc chắn nói rằng đây là khóa học tốt nhất trong số tất cả các khóa học tôi đã trả tiền tại Infron.
Một giáo trình nguyên bản được tạo ra mà không sao chép từ sách, đầy đủ nội dung trong từng bài giảng, không có ý kiến và câu văn vô nghĩa, rõ ràng, tốc độ phù hợp và lời nói rõ ràng, cùng bức tranh toàn cảnh về thiết kế thông qua các phương pháp thực hành cụ thể như kiểm tra. được thực hiện lại dưới nền tảng của thiết kế. Ngay cả khi bạn không nhìn thấy nó, bạn cũng có thể thấy người hướng dẫn đã suy nghĩ, lặp lại, cải tiến và phát triển như thế nào. Ông đã đưa tất cả vào quan điểm trong các bài giảng của mình.
Tôi chưa học một hoặc hai bài giảng của Infron, nhưng tôi chưa bao giờ thấy A/S được thực hiện một cách tinh vi như bài giảng này. Video không phải là thứ có thể chỉnh sửa dễ dàng như văn bản sau khi quay phim, và do tính chất của bài giảng là luôn có mong muốn thể hiện cái gì đó đẹp đẽ và không mắc lỗi nên tôi đã biên tập những phần đó một cách cầu kỳ mà không thêm bớt hay trừ.
Khi người hướng dẫn mắc lỗi hoặc nói: "Ước gì tôi đã làm theo cách này", có những đoạn màn hình chuyển sang màu xám và chỉ nghe được âm thanh. Khi một đoạn như thế này xuất hiện, tôi có thể kiểm tra xem mình có tỉnh táo và lắng nghe hay không, so sánh với suy nghĩ của chính mình và nghĩ rằng người hướng dẫn cũng đang nghĩ về những điều như vậy. Dù sao thì những video A/S này cũng đóng một vai trò rất tuyệt vời. một công cụ giáo dục, giống như một kịch bản có cấu trúc mà tôi đã làm.
Tôi đã mua bản thử nghiệm và nó đi kèm với một thiết kế.
Nhưng thiết kế đắt hơn so với thử nghiệm.
Đây là lần đầu tiên tôi viết bài đánh giá khóa học vì tôi rất tức giận khi thấy chỉ có 54 bài đánh giá cho một khóa học cực kỳ tuyệt vời như vậy. Nội dung, giọng nói, âm thanh, video, độ dài... mọi thứ đều gắn kết đến mức có cảm giác như vậy. Tôi đang nhìn vào một thiết kế đẹp. Cá nhân tôi thích bài giảng của giảng viên Kim Woo-geun hơn nhiều so với bài giảng có tên có 9.999 học sinh.
Khóa học này không chỉ là một khóa học kiểm tra.
Tôi đang tìm hiểu và áp dụng cách sử dụng JUnit và Mockito để viết bài kiểm tra.
Sau đó, ngoài cách đơn giản là sử dụng các công cụ kiểm tra, tôi còn tò mò về mã kiểm tra tốt và mã kiểm tra được xây dựng tốt và tôi đã tìm thấy khóa học này.
Vì tôi rất thích bài giảng đầu tiên của người hướng dẫn nên về cơ bản độ tin cậy của tôi rất cao và nội dung trong mục lục có vẻ thú vị.
Tôi sẽ tham dự tất cả các bài giảng và để lại nhận xét. Bài giảng này không chỉ là bài giảng kiểm tra,
Đây là một bài giảng tuyệt vời giúp bạn suy nghĩ về kiến trúc tốt và OOP.
Đối với tôi, mục đích của việc viết bài kiểm tra chỉ đơn giản là ngăn chặn sự hồi quy.
Kiểm tra và thiết kế bổ sung cho nhau và các vấn đề của kiến trúc phân lớp hiện có,
Bằng cách thông báo cho chúng tôi về những hạn chế của các bài kiểm tra được viết bằng kiến trúc phân lớp,
Nó tự nhiên khiến tôi nghĩ đến thiết kế tốt.
Thay vì chỉ chỉ ra các vấn đề về mặt lý thuyết, nó gợi ý một cấu trúc tốt hơn và viết mã kiểm tra thông qua quá trình tái cấu trúc mã.
Gần đây tôi đã học Mockito lần đầu tiên và rất ấn tượng với thử nghiệm bằng cách sử dụng sơ khai.
Mocktio đã cho chúng tôi trải nghiệm tuyệt vời khi thử nghiệm các thử nghiệm cần thiết bằng Java thuần túy mà không cần bất kỳ thư viện bên ngoài nào.
Cuối cùng, đây là một bài giảng hay tiếp nối thông điệp từ phần 1 rằng mọi thứ đều OOP.
Ngoài ra, thật tốt khi được nghe ý kiến của người hướng dẫn về các khái niệm cần thiết cho bài kiểm tra cũng như mối quan tâm cá nhân của họ. Tôi đã học được rất nhiều điều khi có thể gián tiếp cảm nhận được sự nghiêm túc và thái độ đối với lĩnh vực phát triển.
Cảm ơn bạn vì bài giảng tuyệt vời.
Khi tôi đang học Spring và xem mã về cách viết bài kiểm tra, tôi nhận thấy cách viết bài kiểm tra lặp đi lặp lại, vô nghĩa.
Vì vậy, tôi tự hỏi tại sao tôi lại viết những bài kiểm tra lặp đi lặp lại này. Tuy nhiên, tôi tình cờ thấy một bài giảng mới trên Infrun có tên Tại sao các nhà phát triển thử nghiệm mùa xuân lại thất bại khi viết các bài kiểm tra mùa xuân.
Khóa học này chỉ dành cho tôi! Thế là tôi mạnh dạn thanh toán.
Sau khi hoàn thành khóa học, tôi cảm thấy mình đã lựa chọn và không hề hối hận. Tôi nghĩ rằng tôi đã tạm dừng bài giảng dài 10 phút và suy nghĩ cẩn thận về những gì người hướng dẫn đang nói từng điều một. Vì vậy, mặc dù thời gian giảng là 6 giờ nhưng tôi cảm thấy nó có chất lượng tương đương với 60 giờ.
Tôi xin cảm ơn người hướng dẫn đã mở rộng quan điểm của tôi về công nghệ phần mềm.