Pinned Tweet
After 3 years of hard work I am proud to anounce the an early access version of Testowl is available in the Jetbrains Marketplace.
Testowl is continuous test runner similar to NCrunch or Wallaby.js, but for Java.
Now I am looking for feedback of the community.
💡Your software must not only fulfill the demand that the customer explicitly tells you, but also what he does not tell you and still wants.
#SoftwareQuality
Best way to clean up legacy code? Write behavior-focused tests. Don’t document your dreams—document what’s real.
#CleanCode
Evolutionary design thrives on short feedback loops. TDD gives you those loops. Every passing test = one step forward.
#TDD
Outside-in TDD: Think user first. Inside-out TDD: Build from the core. Good teams know both.
#TDD
The first version of Testowl has been out now for a while. Today there is a preview of version 0.2.0, namely the improvement in test selection. In the current version, adding comments, blank lines or simply formatting the source code leads to test execution. To make working with Testowl even more efficient, in the next version (0.2.0) formatting of the source code that does not represent functional changes will no longer lead to test execution.
Here is a video that demonstrates this use case.
Red flag 🚩: Tests that fail randomly. Flaky tests destroy trust in all tests. Clean them up fast. #CleanCode
Design is never done. Don’t wait for perfect clarity. Step forward, test, refactor. Learn as you go.
#TDD
Interruptions kill focus. Reduce cognitive load: TDD helps you keep your place and pace.
#TDD #Productivity
Global variables, no tests, tangled logic? Don’t panic. Write tests for what it does today. Then refactor in safety.
#CleanCode
When design hits reality, things fall apart. You can’t know everything up front. Evolve as you learn.
#TDD #CleanCode
💡TDD’s not about coverage. It’s a design tool. The tests are just a pleasant side effect.
#TDD
Your house doesn’t need a wrecking ball—just someone to clean one drawer at a time. Same with your codebase.
#CleanCode
Don’t try to clean up legacy code all at once. One test. One refactor. One commit. Apply the Boy Scout Rule."Leave it better than you found it"
#CleanCode
You open a file. 500-line method. No tests. Global state. You're not refactoring — you're defusing a bomb. #CleanCode
Do you know the StringCalculator Kata?
It is a perfect way to practice your #TDD skills.
In this video I am explaining the Kata step by step and guide you also through the code. Have fun.
A clean, trusted test suite catches real bugs. A flaky one trains devs to hit “re-run” and hope.
#CleanCode
A good unit test checks behavior—not lines of code. Code changes. Behavior is forever.
#TDD
Today while doing TDD, I came across a scenario that I’ve noticed a few times before but haven’t really paid much attention to until now. The scenario is as follows: you start with a test as usual. As it often happens, the test consists of several assertions. Now, one could argue about how many assertions make sense in a single test—but I don’t want to start that discussion here.
Here’s what I’m focusing on: while writing the first assertion, the test already fails. This is especially noticeable when using a continuous test runner; otherwise, at that point, you might not even run the test yet.
Now you have two options:
Option 1: You first complete the entire test and then start working on the production code as usual.
Option 2: As soon as the test fails, you immediately jump to the production code, fix the failing test, and then continue working on the test.
Option 2 is my preferred approach. It allows for smaller steps and therefore even faster feedback. One could argue, of course, that you don’t need steps with such fine granularity. But this just offers another way to make your steps even smaller.
What I’m curious about is what TDD experts think about this. Do you occasionally encounter this scenario? And if so, how do you deal with it?