When your unit tests are poorly written... 😆
Chema
chemaclass@snort.social
npub1ch2g...sxwx
I like open-source software and sharing knowledge
When doing TDD, make sure the test fails for the right reason. That's more important than we tend to think. Seeing the test red (for the right reason!) is crucial to make sure what you are doing (make it pass) is the right thing to do. And then you can refactor with confidence 🏗️
A great way to learn (and improve!) a programing language is by practicing it with others. And for this, Open-Source Software is one of the best opportunities we all have out there.
You can start fixing some typos, translating something to your mother-tongue language (if applicable), writing some docs, or applying simple refactoring opportunities... until you get comfortable and you can start applying bigger refactorings or even contributing to adding entirely new features.
You don't want to test "private methods" but "public behavior". Private scope is about implementation details.
If happens that you feel the need to test a private method, it will luckily be that your class is responsible for multiple things.
TIP: Consider extracting that private method to another class, and create an interface to invert the dependencies between them. This way you will make your behavior testable.
Adding `ktlint` now results in a big PR (changing many files), but I think it's a nice investment for the scalability of the project. What do you think, #[0] ?
GitHub
Add ktlint by Chemaclass · Pull Request #220 · vitorpamplona/amethyst
📚 Description
A linter is basically a small program that checks no errors/bugs are introduced, additionally, it defines a set of rules that the ...
In the context of building software, think about constant and small iterations. This way, you can adapt quickly to the different needs along the way.
Good morning, team! Second week of March. There we go! 🤘
Your code quality is directly proportional to how easy it is to write automated tests for it. As simple as that.
If you cannot build it in one day, the problem is too complex. Break it down and/or find a smaller problem that you can solve in a day that helps you work towards the greater goal.
Reduce friction for good habits and increase friction for bad habits.
Reduce friction for good habits and increase friction for bad habits.
Yes! You cannot build the perfect and right software from the very beginning. However, you can collaboratively work toward better software on the daily basis.
Make the code work first. Then clean it up. The more you delay cleaning your code up, the more tech debt your project will accumulate.
With the right knowledge, environment, and support structure, everyone is capable of upgrading themselves.
Test-Driven Mentality is the key 🔑