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).
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. …
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. …
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.
📝 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.
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. …
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:
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.
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. …
As a disclaimer, this is solely my point of view.
If you don’t understand the advantages of pairing, perhaps you should start with that. Let’s quickly recap them:
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”.
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).