Pour tester la capacité de votre navigateur à vous protéger des fingerprint

When my new insulin pump’s algorithm confidently delivered what it claimed were hefty doses while my blood sugar soared toward dangerous levels, I faced a terrifying reality: the software was learning, but learning the wrong things.

And it was utterly convinced it was doing a great job.

This isn’t just a medical device story - it’s a wake-up call for our entire industry. As ML and AI become critical infrastructure, they’re exposing fundamental flaws in how we approach quality. We test implementation rather than behaviour, write tests that validate our assumptions rather than challenge them and mistake comprehensive coverage for genuine safety.

Drawing from 15+ years as a software engineering trainer and consultant across multiple industries, I’ll explore how traditional testing blind spots become genuinely dangerous when systems learn and adapt. We’ll examine why teams confuse feeling safe with being safe, how AI amplifies our existing quality gaps and what it really means to test systems that make decisions affecting real lives.

You’ll leave with practical approaches to testing that focuses on impact over metrics, strategies for validating both deterministic and learning systems, and the essential questions every team should ask when software moves beyond just processing data to making decisions that matter.

Because whether it’s a payment system, a recommendation algorithm or life-critical medical software, our users are trusting us to get it right.

The edge cases between the edges

T shaped but untrained in testing

Quelques invitations :

1. Create an interaction matrix for your edge cases
2. Write Property Based Tests for your constraints
3. Implement chaos engineering for your business logic, not just your infrasctucture
4. Document and test your "must never" invariants explicitely (ex. MUST_NEVER.md
5. For ML systems specifically, test the decision boundaries, not just accuracy
6. Build observability into your business logic, not just your infrastructure
7. Implement feature flag controls for rule interactions
8. Use your Threat Model
9. Get to know all the people and what they need
10. Ask the uncomfortable question

Would I trust this system... With my wealth ? My Freedom ? My Life ? -> Meeh, or No and you put it out in production, SHAME ON YOU.

During his Codecamp Romania 2025 Masterclass, J. B. Rainsberger answered some questions about software design.

Here are four lightning talks in which he addresses these topics:

1. When not to do TDD and one surprising disadvantage for experienced TDD practitioners.
2. How Client-First Design addresses one of the common shortcomings of naively allowing designs to evolve from the ground up.
3. Adding safety to refactoring without assuming that adding tests is enough or indeed the best choice.
4. Two kinds of refactoring activities and how to communicate the need for each of these to non-programmer members of your project community.

Les surcouches d'accessibilité ne sont pas une bonne idée.

• approved picture
• apporved log

The secret to working faster with AI isn't better prompts, or bloating your AGENT.md. It's all about managing cognitive load, habits, and creating systems that let your agent work unsupervised.

Speaker bio: Ivett Ördög is a Samman technical coach with over 30 years of coding experience. She helps engineering teams tackle legacy systems and work effectively with AI coding agents. She is the creator of the @NextIncrement YouTube channel and serves on the board of the Samman Technical Coaching society since 2025.

Automated tests are important. Without them, programmers waste a huge amount of time manually checking and fixing their code.

Unfortunately, many automated tests also waste a huge amount of time. The easy, obvious way to write tests is to make broad tests that are automated versions of manual tests. But they’re flaky and slow.

Folks in the know use mocks and spies (I say “mocks” for short in this article) to write isolated interaction-based tests. Their tests are reliable and fast, but they tend to “lock in” implementation, making refactoring difficult, and they have to be supplemented with broad tests. It’s also easy to make poor-quality tests that are hard to read, or end up only testing themselves.

Bad tests are a sign of bad design, so some people use techniques such as Hexagonal Architecture and functional core, imperative shell to separate logic from infrastructure. (Infrastructure is code that involves external systems or state.) It fixes the problem... for logic. But infrastructure is often left untested, and it requires architectural changes that are out of reach for people with existing code.

This pattern language1 describes a fourth option. It avoids all the above problems: it doesn’t use broad tests, doesn’t use mocks, doesn’t ignore infrastructure, and doesn’t require architectural changes. It has the speed, reliability, and maintainability of unit tests and the power of broad tests. But it’s not without tradeoffs of its own.

1The structure of this article was inspired by Ward Cunningham’s CHECKS Pattern Language of Information Integrity, which is a model of clarity and usefulness.
The patterns combine sociable, state-based tests with a novel infrastructure technique called “Nullables.” At first glance, Nullables look like test doubles, but they're actually production code with an “off” switch. And that’s the tradeoff: do you want that in your production code? Your answer determines whether this pattern language is for you.

The rest of the article goes into detail. Don’t be intimidated by its size. It’s broken up into bite-sized pieces with lots of code examples.

Au delà de la pyramide des tests.

Des propriétés désirables de tests.

Disclaimer: This post is not about lighthouse, other testing tools perform similarly. It's about us developers and our responsibility to not thoughtlessly rely on automatic testing.

It’s always nice to see when people post their Lighthouse scores on social media to highlight how well they’ve optimised their own or their client's website. It shows that they care about the quality of what they build.