well-described task is at least half of the story behind its successful implementation. Some other success factors are hidden in what happens to the task further down the road and especially in how the necessary feedback is provided and processed in the task implementation.
With Ruby on Rails as our primary backend technology, we have developed a set of practices for testing our applications. Our goal was to maximize the efficiency of writing tests that cover the most critical parts of the software built.
Naming things in programming may not be hard (a matter of imagination), but it is definitely hard to do it right. Also, it turns out to be very unclear what “right” means in each and every context. It doesn’t change the fact that in 8 out of 10 PRs I review, I provide a feedback related to naming, be it naming of classes, methods, fields, variables… you name it
A curated list of git commands enough to keep your git history flat I’ve been working on projects where we keep the git history flat (no merge-commits) for quite a bit of time now, and I’ve decided to make a list of git commands I often use during every-day development.
Have you ever thought about writing a technical article to share your knowledge with others and had no clue how to do so? You are in the right place. In this article I will try to guide you through the entire process and highlight the parts you should pay special attention to.
In the previous part of this article we focused on making specs we try to write as readable as possible. This however, comes at a cost of duplication and bloated individual tests. While this is a cost we intend to pay, there are ways to mitigate the impact of readability oriented specs on the overall size of our suite.
Form Object is a very useful pattern in rails ecosystem as it can address variety of issues and antipatterns. In this article we will attempt to sort out in which situations Form Objects can prove useful and what conventions allow us to make most out of them.
Clients and Wrappers (also referred to as “Facades”) are remarkably useful tools for working with external services, libraries or APIs. While both Clients and Wrappers are primarily used to facilitate usage of before-mentioned libraries or APIs, there are some significant differences in responsibilities each of these patterns have. In some cases a Wrapper can take over a Client’s responsibilities too
In part 1 we have covered antipatterns related to stubbing and problem with implementation details that are a overcomplicated just for the sake of being super easy to tests. In second part we are going to focus more on tests themselves.
When preparing our test suite we might be tempted to make some shortcuts that will render our tests less readable, comprehensible or will significantly decrease the flexibility of further implementation. Below, I try to list some of the most commonly seen techniques we should avoid to keep our test suite healthy.
It is hard to underestimate a value and importance of automated tests. Creating confidence about if the code works the right way and thus enabling safe refactoring is just one thing. Another one is that test suite can act as a way to document behavior and also, especially when approached the BDD way, can drive the code design and architecture.
