(Clean Architecture) Testable Architecture

Copyright

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 일곱번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 저작자님께 게시허가도 받았습니다.

Content

1. Clean Architecture

2. Domain-centric Architecture

3. Application Layer 

4. Commands and Queries (CQRS)

5. Functional Organization

6. Microservices

7. Testable Architecture

8. Evolving the Architecture

Outline

Test-Driven Development

Test Automation Pyramid

Pros and Cons

Test-Driven Development

Test-Driven Development is a software practice where we create a failing test first before we write any production code, and use this test to drive the design of the architecture.

1. Create a failing test for the simplest piece of functionality we need to create.

2. Get the test to pass (implement just enough production code to get that failing test to pass)

3. Improve the code (refactor our existing code)

4. Repeat 1~3 steps

TDD

Comprehensive suite of tests

Drives testable design

More maintainable

Eliminates fears to change

Types of Tests

What to test : Unit tests, Integration tests, Component tests, Service tests, UI tests

Why being tested : Functional tests, Acceptance tests, Smoke tests, Exploratory tests

How being tested : Automated tests, Semi-automated tests, Manual tests

Acceptance Tests

1. Eliminate user interface then replace to Acceptance Tests

2. Eliminate database then replace to in-memory Database

3. Eliminate dependencies in the infrastructure and cross-cutting concerns layer then replace to fake test doubles called mocks that act as surrogates for the real dependencies

Acceptance criteria should be written in the language of the business to describe business functionality that the application needs to provide.

Focus on the essential, and not implementation details

Minimize coded UI tests, Smoke test instead     

Minimize manual tests, Exploratory test instead

Why Create Testable Architecture?

Pros

Easier to test

Improves design

Eliminates fear to change code

Cons

Higher up-front cost

TDD requires discipline

Requires team buy-in

Demo

Uses NUnit, Moq, AutoMoq, SpecFlow

출처

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 일곱번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 제가 정리한 것보다 더 많은 내용과 Demo를 포함하고 있으며 최종 Summary는 생략하겠습니다. Microsoft 지원을 통해 한달간 무료로 Pluralsight의 강의를 들으실 수도 있습니다.