There are some things we keep hearing and doing but we seldom question, like “code comments are good” or “magic numbers are bad”. Let’s address the latter.
Creating constants can be a symptom of some underlying anti-patterns. But aren’t magic numbers (or strings, etc.) a bad practice? Well… don’t follow rules just because you always did it. Let’s address the typical arguments (we’ll use Kotlin in the snippets).
“But I can use them in the tests!”
This is the worst reason to create constants. Tests should know nothing about the implementation other than its public APIs. Initially, a certain constant was local/private but you promoted it to global for the sake of testing. This was a bad idea because now the tests are coupled with the implementation. Tests should be seen as clients of the implementation (i.e. …
Testing is more than creating a safety net.
In an agile mindset, the team is responsible for the delivered software, which includes quality assurance (QA). In this scenario, QA is a role that is adopted by the team as a whole — developers should be writing automated tests. Manual testing does not scale as it’s hard to reproduce, tedious, error-prone, and not compatible with continuous delivery. However, if there are QA specialized people, they should be doing other types of work (e.g. exploratory testing), but I’ll leave that for another article.
Automating everything — from build to tests, deployment and infrastructure — is your only way forward. …
In Kotlin/Java, how would you test that your app is properly consuming an external REST API? We’ll use Javalin to do it.
My proposal is to use Javalin — a lightweight webserver — to simulate an external API. The trick is to launch it acting as the real API but running in localhost. Therefore, the gateway—the component under test — can’t tell the difference.
How do you ensure that two given components speak the same language? Do you have invalid values floating around? Would you represent dates as strings internally? Then why do you represent your domain concepts as strings and integers? It makes no sense.
Value objects are one of the building blocks of domain-driven design. Let’s explore their main characteristics.
📝 Value objects make sense in most languages, object-oriented or not. We’ll use Kotlin.
⚠️ If any Kotlin Playground example fails to load, refresh the article or open the legend’s link.
Value wrappers
The value object is a container and carrier of an arbitrary value:
Usually, value objects hold a single value, but this is not always true. For example, a 3D point holds three numbers; an RGBA color holds 4 integers.
📝 Java enums are a native example of value objects but they’re not adequate for an arbitrary amount of values. Typical value objects are: email, password, locale, telephone number, money, IP address, URL, entity identifier, rating, file path, point, color, date, date range, distance. …
I see some people struggling to write a unit test. I remember that pain some time ago. This is the article I wish I have read back then. I’ll present a systematic approach to write unit tests.
Test-Driven Development — TDD puts the test in the spotlight: it’s how you drive your implementation. TDD forces you to separate the “what” (test) from the “how” (implementation) so you can focus at one at a time. That’s why it can also be seen as Test Driven-Design and why the test is also known as spec (i.e. specification).
When learning TDD, you’ll hear a lot about the TDD cycle. What is that? It’s just a fancy name for the typical TDD state transitions between test/design → implement → refactor:
Sometimes it’s easier to learn from ‘what not to do’ rather than from ‘what to do’. Anti-patterns represent common bad practices, code smells and pitfalls, in this case, when creating automated tests. You should learn them so that you can spot them.
Creating patterns to describe something creates nomenclature. Once you have a name for something, it’s easier to recognize when you see it again.
The Productive Programmer, Neal Ford
📝 The list applies regardless of the language/runtime.
No clear structure within the test
Not following an expectable structure in each test makes it hard to maintain it. Tests are living code documentation, so everyone should be able to quickly read/change them.
Arrange, Act, Assert is a pattern for structuring code in test methods. Basically, you organize your code in phases for the sake of clarity. …
Assuring quality on the demanding software products we build at Volkswagen SDC:LX is not easy. Saying we’re agile is not enough, so I’ll present the soft and hard factors that ensure the required standards are met.
As a disclaimer, this is solely my point of view.
Culture
- Team members are part of the hiring evaluation stages, which greatly improves compatibility and ensures the culture and methodology continuity.
- Critical thinking is highly appreciated and everyone is free to challenge what’s defined and the others (regardless of the role). This is supported by our non-judgmental environment.
- We rely on a scientific approach to problems by setting hypotheses and assumptions and seeking to confirm or disprove them.
- Team empowerment fosters ownership: since the team is responsible for the product (building and operating it), everyone is more dedicated to it. …
Pairing is not just two people working together. Mutual respect, emotion management, and other psychological factors come into play. Doing it well takes time, so be patient, repeat it properly until you can reach the “pairing zone”.
If you don’t understand the advantages of pairing, perhaps you should start with that. Let’s quickly recap them:
- You’re “forced” to put your thoughts and ideas into concrete words, which contributes to solving problems and helps you consolidating knowledge;
- Pairs complement/help each other (e.g. you don’t get stuck for hours in a bug); you move steadily and with increased predictability; you feel useful at the end of the day;
- The focus is higher since you have to respect your pair’s time and effort (e.g. you won’t be checking your phone every time) and you’ll have someone helping to manage time (e.g. …
An autonomous UI doesn’t rely on animations, sound, colors, shortcuts, and help to be understood and used. It doesn’t mean it shouldn’t have them but it shouldn’t depend on them.
Animation
Animations help to reinforce the chosen visual metaphor (e.g. a slide right to express a card removal; a loader to show there’s some background job) and create visual harmony (e.g. to soften transitions). They should be simple, tenuous, used consistently (e.g. fade in vs fade out to express opposite concepts). Use them in moderation and if they bring value. Animations aren’t supposed to be constantly noticed by users, as they’d be distracting from what matters. They shouldn’t be used just to “make the app cooler”.
Excessive and heavy animations can be really bad, consuming lots of CPU time or being harmful to people with certain disabilities (e.g. …
With the rise of UX practice as a pillar of effective human/machine communication, many developers are still unaware of its importance. Let’s go through some guidelines.
1. Prototyping and iterating
Great UIs are not easy to achieve and may require several iterations until the ideal solution is designed — the one less complex but providing all the functionality. Paper prototyping of a user interface is a technique that lets you iterate quickly and cheaply. It produces low fidelity (lo-fi) prototypes (throw-away prototype, mockup or wireframe).
About
