Skip to content

Review chapter 27 #386

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Review chapter 27 #386

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 17 additions & 3 deletions chapter_27_hot_lava.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ and the end of our journey with this To-Do app and its tests.
Let's recap our test structure so far:

* We have a suite of "functional tests" that use Selenium to test that the whole app really works.
On several occations, the FTs have saved us from shipping broken code,
On several occasions, the FTs have saved us from shipping broken code,
whether it was broken CSS, a broken database due to filesystem permissions, or broken email integration.

* And we have a suit of "unit tests" that use Django's test client,
Expand Down Expand Up @@ -175,6 +175,9 @@ The problem is that these things don't scale linearly.
The more database tables you have,
the more relationships between them,
and that starts to increase geometrically.
// SEBASTIAN: That holds true as long as relationships number grows with database tables.
// I would add here or in the section about architecture that keeping project decoupled by having autonomous modules
// will replace geometrical penalty increase with linear one.

So you can see why, over time, these kinds of tests
are going to fail to meet our desiderata because they're too slow
Expand Down Expand Up @@ -313,6 +316,8 @@ Often people use it to mean the same thing as functional tests or end-to-end tes
But as taught to me by one of the legends of QA at MADE (hi Marta!),
_any_ kind of test can be an acceptance test,
if it maps onto one of your acceptance criteria.
// SEBASTIAN: Great point! I think of acceptance tests as part of second, parallel classification of tests.
// Unit tests, for example, are about scope of SUT. Acceptance tests are about purpose of testing.

The point of an acceptance test is to validate a piece of behaviour
that's important to the user.
Expand Down Expand Up @@ -347,6 +352,10 @@ the use of mocks comes with painful trade-offs.
* And in the extreme, you can sometimes end up with mocks testing mocks,
almost entirely disconnected from what the code actually does.

// SEBASTIAN: Tight coupling to implementation details is debatable. That happens if one mocks whatever they feel like.
// If one mocks 'stable interfaces', e.g. Gateways or Service layer of another 'unit'/'module' then it's not coupling to implementation details
// Perhaps there is some middle-ground here, like Mocks lead us astray to mock whatever stands in our way and skipping this part of building solid abstractions?

Ed Jung calls this https://youtu.be/CdKaZ7boiZ4[Mock Hell].

This isn't to say that mocks are always bad!
Expand Down Expand Up @@ -407,7 +416,7 @@ because "Cosmos" is the opposite of "Chaos", in Greek.
*******************************************************************************


==== Ports and Adapters/Hexagonal/Onion/Clean Architecture
==== Ports and Adapters/Hexagonal/Onion/the Clean Architecture

The classic solutions to this problem from the OO world
come under different names, but they're all variations on the same trick:
Expand All @@ -424,7 +433,9 @@ image::images/twp2_2601.png["Illustration of ports and adapaters architecture, w

This pattern, or variations on it, are known as
"Hexagonal Architecture" (by Alistair Cockburn),
"Clean Architecture" (by Robert C. Martin, aka Uncle Bob),
"the Clean Architecture" (by Robert C. Martin, aka Uncle Bob),
// SEBASTIAN: it's "THE Clean Architecture", not just "Clean Architecture".
// https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
or "Onion Architecture" (by Jeffrey Palermo).


Expand Down Expand Up @@ -486,8 +497,11 @@ that it can provide them most of the feedback they need about whether the system

Not everywhere is Facebook! But it's a good indication that automated tests
aren't the be-all and end-all.
// SEBASTIAN: This could use a mention of "shift-right" and perhaps a link or two in further reading to discover this fascinating world of testing in prod
*******************************************************************************

// SEBASTIAN: In this section, I very much miss any mention about internal project's modularity, such as can be achieved by using 'vertical slices'.
// Shameless plug: in my book, I devoted a whole chapter to it. From maintainability perspective, it's much more rewarding in the long term than horizontal slicing or decoupling from IO/external world as achieved with P&A/the Clean architecture etc.

=== The Hardest Part: Knowing When to Make the Switch

Expand Down
Loading