Refactoring towards the Liskov Substitution Principle

Sunday, January 4, 2015

Sometimes you write or encounter a method that return an object that represents a complex result upon which the caller should decide how to proceed. For example, consider the method with the following signature: StudentQueryResult FindStudent(string nameSubstring); This method looks for a student by his name or part (substring) of it. This method can have 3 possible return values: 1. If there's no student found that matches the substring, it should return null 2. If there's exactly one student that matches the substring, it should return all of the details about this student, including the list of courses he completed and the...

TDD, SOLID, Functional Programming, Declarative programming and more…

Thursday, December 19, 2013

TDD and the Single Responsibility Principle Amongst the 5 SOLID principles, I found that the one which is the least tangible is the “Single Responsibility Principle” (SRP). Even though this is the most well-known and intuitively easy to understand, the questions “What exactly is ‘Responsibility’?” or “How do you determine whether a class has exactly one Responsibility?” is not trivial whatsoever. Obviously there are many cases that the violation of this principle is evident, but there are many more which fall in the grey area. It’s often being claimed that TDD helps guide you to develop classes which adhere to the...

Main Pitfall of TDD–Refactoring

Monday, May 27, 2013

Many people have bad experience with TDD. Their main complaints are: They spend too much time maintaining tests. For example, to fix a small bug or a small change in the production code they need to fix many tests Even though they follow the TDD practice and always write tests before production code, the production code doesn’t become so “clean” and SOLID. It’s difficult to write tests that cover all lines of code and all cases Tests need very long and complicated setups of mock objects...

Online materials from my Expert Days sessions

Saturday, December 29, 2012

Thanks for those who participated in my sessions in Expert Days! I hope you enjoyed it. For your benefit and also for everyone else that didn’t participated, I uploaded all the materials online so you can browse whenever you want. You can find all the materials here. In the above link you’ll find the following files: For the “C# in Depth” session you’ll find: The presentation All the demos (except for the Roslyn project demo) The Roslyn project demo For the “Software Quality –...

Test driving interactions using Async and Await

Saturday, September 15, 2012

From time to time I encounter a problem that seems pretty straight-forward to implement without TDD, but very cumbersome to do with TDD. Most of these cases have something in common: they describe interactions between the tested component and external parties. These external parties can be either the user, external system, or any kind of communication protocol. Here’s the simplest example I could think of: This is a simple console application that asks the user for his name, and then greets him with “Hello, “, followed by his name. Writing this application takes exactly 3...

Avoiding Conway’s Law using TDD and ATDD

Wednesday, July 11, 2012

Back in 1968, Melvin Conway stated that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations". This statement is still relevant today and is well known as the Conway’s Law. There’s a lot of truth in this observation, and many organizations take this law seriously and structure their development organization to best reflect their desired architecture. The desired outcome of such organizational structure, which is mostly achieved, is that each component is cohesive, loosely-coupled from the other components, and also pretty well maintained by the team –...

ATDD with MS-Test or NUnit

Tuesday, May 29, 2012

Normally ATDD and BDD are associated with special tools that allow non-developers like business people and testers write or at least read tests, without having to write code. Examples of such tools are FitNesse, M-Spec, SpecFlow, Cucumber and more. However, even though these tools allow to specify tests scripts without code, often for business analysts these tools are too technical, or they just don’t have the mindset to specify tests in a well-structured “Given-When-Then” format. About two years ago, the core group in Retalix tried to adopt ATDD using FitNesse, where the BA’s (Business Analysts)...

Guidelines for writing good automated tests

Monday, April 30, 2012

Hi everybody! Recently I was appointed to lead the test automation and TDD efforts in Retalix’s development group. As part of this effort, I realized that most people lack the knowledge of how to write good tests, and their mistakes lead to tests that are a pain to maintain, or give doubtful ROI. So I ended up putting this short guidelines on the internal Wiki. However, I thought that it should be useful to share it with everyone. What kind of tests these guidelines refer to? Any functional automated tests. That is automated tests that...

Worst VS feature: Copy & Paste

Wednesday, March 21, 2012

Time and time again, when I'm reviewing code of pretty experienced programmers, I'm still shocked how they're using Copy & Paste programming extensively instead of extracting common code to shared methods and classes. Visual Studio and many 3rd party add-ons tools make it very easy to make these refactoring that allows to avoid any duplication. But still – Copy & Paste is easier and that's what many programmers use by default. Frankly, I chose the title for this post just to tease. Clearly there's nothing wrong with the Copy & Paste feature of Visual Studio. The problem is...

Do you really code-review? (Or: to pair or not to pair?)

Friday, February 10, 2012

There’s no doubt that Code review is an important practice. It has many advantages: · Bugs are likely to be found early · The quality and especially the readability of the code are kept high · Technical knowledge and experience is shared · Domain knowledge is shared In most organizations I encountered, some kind of code-review policy was in place. However, not many of them succeeded in implementing the policy. The main “excuse” is usually pressure, but in my opinion, the problem is deeper than this as I'll explain later. Another practice,...
no comments