berkes 🐝 🚐 🏄 🌱 @[email protected]

Zaza is fed up with the rain and storm.🍁🌧️

"If you can’t fit everything you want to do within 40 hours per week, you need to get better at picking what to do, not work longer hours."

@dhh and @jasonfried in "It Doesn’t Have to Be Crazy at Work"

production down. Me frantically clicking through AWS.

"But I added those SSL connections to the load balancers! why are they not there! What is removing them?" 😱

Nothing was "removing" them.

There was a *second* "Apply" button far below. Obviously I forgot to click that before navigating away. UX matters even if your audience is 100% tech-nerds. (and yes, I should've used the CLI or cloudformation, I know)

In the 19th century, Europeans offered the Cree in Manitoba higher prices for furs, hoping to buy more. In response the Cree brought fewer furs to the trading post,since a smaller number were now needed to obtain the goods that they wanted in exchange. From Doughnut Economics

Complexity is your enemy, any fool can make something complicated. It is hard to make something simple

- Richard Branson

Are there cases when tests are waste? I don't think so.

Tests are great for exploring an API, framework or Library.
Tests are an automation framework. I hate repeating labor. Clicking around through the same feature, fifty-five times a day, when developing it: that is waste!

Manual tests are important too. They achieve three things. 1. Get a feeling how users experience the app. 2. 3. Bore the hell out of me.

Automate! All! Things!
But keep testing manually.

(Just make sure you don't do like me and test with nonsense like "lalala")

E2E tests achieve three things, four if you do TDD/BDD: 1. Ensure critical features work for users. 2. Specify what a feature does (user-story-style). 3. Stay on top of performance(degradations). 4. Build only what is needed for a feature.

Integration tests achieve two things three if you do TDD: 1. spec the business/domain-logic 2. test that classes and layers are wired up properly 3. Ensure we don't build stuff that is not needed (YAGNI).

Unit tests achieve two things, three if you do TDD: 1. cover all paths & nooks-and-crannies. 2. spec how a class/unit/boundary works *for a developer*. 3. teach early on about design and architecture issues.

The testing-pyramid explains most layers (good alternatives for the pyramid here: https://medium.com/@mateuszroth/why-the-test-pyramid-is-a-bullshit-guide-to-testing-towards-modern-frontend-and-backend-apps-4246e89b87bd).

They boil down to: "e2e", "integration", "unit". Depending on my architecture, I may need additional ones, but at least these three.

Developers often ask me "What to test"? The answer is always "Everything!"

Always, everything. The question is really How, not What. How to test everything? Well, TDD!. But a good organization of tests too. There are many different types of tests. And we always need all.