Tag Best Practices
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 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.
Test-induced design damage or why TDD is so painful
I’m going to write a couple of posts on the topic of TDD. Over the years, I’ve come to some conclusions of how to apply TDD practices and write tests in general that I hope you will find helpful. I’ll try to distil my experience with it to several points which I’ll illustrate with examples.
-
Test-induced design damage or why TDD is so painful
Encapsulation revisited
The third most important software development principle is Encapsulation.
KISS revisited
Today, I’m going to discuss the KISS principle. I consider it the second most valuable software development principle.