DRY revisited
Another principle we should follow when building a software project is the DRY principle. The abbreviation stands for Don’t Repeat Yourself. While it seems pretty straightforward and intuitive, this principle is more than meets the eye. Let’s see how it is so.
Cohesion and Coupling: the difference
This is another post on the most valuable principles in software development.
You might have heard of a guideline saying that we should aim to achieve low coupling and high cohesion when working on a code base. In this article, I’d like to discuss what this guideline actually means and take a look at some code samples illustrating it. I also want to draw a line between these two ideas and show the differences in them.
Database versioning tools
The topic described in this article is a part of my Database Delivery Best Practices Pluralsight course In the previous two articles, we looked at the theory behind the notion of database versioning. Today, I want to dive into practice and discuss the database versioning tools available at our disposal. Database versioning tools classes The tools on the market can be divided into two classes: those which follow the state-based approach and those that adhere to the migration-based principles.
State vs migration-driven database delivery
The topic described in this article is a part of my Database Delivery Best Practices Pluralsight course In the previous post, I wrote about the database versioning best practices. I’ve got a lot of feedback on that topic. One of the responses stated that the article was (admittedly) one-sided as it didn’t cover the other widely spread approach to managing the database delivery process. I decided to fill that gap and provide my own comparison of the two.
Database versioning best practices
The topic described in this article is a part of my Database Delivery Best Practices Pluralsight course. Keeping track of your application’s database is not an easy task. Database schemas tend to mismatch in different environments, data in one of the databases may miss some crucial piece of data. Such occasions can be irritating, especially when caught in production. The situation gets worse when you develop redistributable software. In this case, each of your clients has their own database instance whose structure may differ from others'.
TDD best practices
Last week, we discussed the differences between stubs and mocks. Today, we’ll talk about some general tips and advice that regard to TDD and writing tests in general.
Stubs vs Mocks
In this article, I’d like to discuss the differences in using stubs and mocks and show how you can abandon using mocks even in the cases where you need to verify that objects interact with each other correctly.
The most important TDD rule
In the previous articles, we discussed what causes the pain while writing unit tests (mocks), and how to make TDD painless (get rid of the mocks). Today, I want to set the groundwork and discuss why mocks actually cause so much pain to us, developers.
Integration testing or how to sleep well at nights
Unit testing is good at checking the correctness of your code in isolation, but it’s not a panacea. Only integration tests can give us confidence that the application we develop actually works as a whole. They are also a good substitute for mocks in the cases where you can’t test important business logic without involving external dependencies.
-
Integration testing or how to sleep well at nights
How to do painless TDD
Last week, we nailed the root cause of the problems, related to so-called test-induced damage - damage we have to bring into our design in order to make the code testable. Today, we’ll look at how we can mitigate that damage, or, in other words, do painless TDD.
