EngineerSpock

SOLID Principles: Interface Segregation Principle (ISP)

EngineerSpock — Thu, 27 Dec 2018 16:03:22 +0000

In this part of the SOLID series, we’re going to revisit the ISP or Interface Segregation Principle. Yep, this is a very long article. If you want an easier way of learning SOLID principles in depth, then I would recommend you taking my SOLID tutorial just for 10.99$.

Interface Segregation Principle Definition

Before giving a definition, I want to say a couple of words about what we mean here by the word “interface”. Of course, “interface” is a reserved keyword in C# which allows to declare a non-implementable type consisting of member signatures. Such a construction defines an API, a shape which has to be implemented by inheritors of that interface.

At the same time, it’s not necessary to implement an interface to expose an interface. What I mean is that classes which don’t implement any interfaces have their own interfaces comprised of publicly visible members. The set of public members of a class represents the interface of that class. So, simply put, an interface is what clients see and use.

A great simple definition of the Interface Segregation Principle was given in the book you have already heard of, “Agile Principles, Patterns, and Practices in C#”. So, the definition is:

“The Interface Segregation Principle states that Clients should not be forced to depend on methods they do not use.”

A simple conclusion that we can draw from this definition is that you should prefer small, cohesive interfaces to “fat” interfaces. Just in case, I’ll remind you that “cohesive” means that all the API members are logically related to each other.

It’s always useful to look at a picture which illustrates the problem. And of course, this is also a chance to get some fun. Look at this illustration.

This funny monster wants to eat and that’s why it says that if IRequireFood, then it means that I want to Eat some food, not light candelabra or layout cutlery. This obviously implies that if you have a public interface named IRequireFood, it would be silly to have methods like LaunchAircraft or KillCharacter exposed by that interface.

A bit of History

Here is an interesting historical note about the ISP. I’m pretty sure that ISP was first used long ago before Robert Martin, but the first public formulation belongs to Robert C. Martin. He applied the ISP first time while consulting for Xerox. Xerox had created a new printer system that could perform a variety of tasks such as stapling and faxing. The software for this system was created from the ground up. As the software grew, making modifications became more and more difficult so that even the smallest change would take a redeployment cycle of an hour, which made development nearly impossible. The redeployment cycle took so much time because at that time there were no C# or Java, these languages compile very fast. What we can’t say about C++ for example. Bad design of a C++ program can lead to significant compilation time. The consequences are dramatic.

Let’ get back to the story. The design problem was that a single Job class was used by almost all of the tasks.

Whenever a print job or a stapling job needed to be performed, a call was made to the Job class. This resulted in a ‘fat’ class with multitudes of methods specific to a variety of different clients. Because of this design, a staple job would know about all the methods of the print job, even though there was no use for them.

To solve the problem, Uncle Bob came up with an idea which is called “Interface Segregation Principle” today. Uncle Bob created an interface layer between the Job class and its clients using the Dependency Inversion Principle (that we’re going to cover later).

Instead of having one large Job class, a Staple Job interface or a Print Job interface was created that would be used by the Staple or Print classes, respectively, calling methods of the Job class. Therefore, one interface was created for each job type, which were all implemented by the Job class.

So, Interface Segregation Principle violation results in classes that depend on things they do not need, increasing coupling and reducing flexibility and maintainability.

Interface Segregation Principle Violation in C#

I want to show you a real case from my practice which was related to the problem of interface segregation. I’ve been working with devices a lot and once I faced the following case.

Before continuing I want to say that I like to give examples to students which reflect the whole picture of a real-world case, so I’ll describe all the details related to the problem because I think that this helps to understand the material much better.

So, on the top level, we have a monolithic WPF application which works in POS terminals. Those terminals allow people to buy tickets on suburban trains. That application allows users to buy tickets via credit cards. Thus, the application has to work with bank terminals somehow. Due to some business reasons, there were several bank terminal models integrated to POS-terminals, so all of them had to be supported. The interoperation with bank terminals is not direct, bank terminal producers provide their own applications through which our application can work with their bank terminals. Their applications are implemented as COM-servers. If you don’t know what is a COM-server, just think of it as of a standalone executable service. The following diagram reflects the flow of operations:

Let’s look at the code:

[code lang=”csharp”]
public interface IBankTerminal
{
void Start();
void Stop();
void Ping();
void BankHostTest();
void Purchase(decimal amount, string checkId);
void CancelPayment(string checkId, decimal amount);
void InterruptTransaction();

event EventHandler PaymentCompleted;
event EventHandler CancellationCompleted;
event EventHandler TransactionCompleted;
}
[/code]

There is a bare minimum of operations which are supported by any possible bank terminal. That’s why I defined the IBankTerminal interface which reflects the API provided by services which interoperate with bank terminals directly.

Now I have three implementations of the IBankTerminal interface: ZapTerminal, ZonTerminal and PdqTerminal.

[code lang=”csharp”]
public class PdqTerminal : IBankTerminal
{
private PdqTerminalServiceCommunicator _service = new PdqTerminalServiceCommunicator();

public void Start() { }
public void Stop() { }
public void Ping() { }
public void BankHostTest() { }
public void Purchase(decimal amount, string checkId) { }
public void CancelPayment(string checkId, decimal amount) { }
public void InterruptTransaction() { }

public event EventHandler PaymentCompleted;
public event EventHandler CancellationCompleted;
public event EventHandler TransactionCompleted;
}
[/code]

I omitted the real implementation since it would complicate the example too much and there is no meaning to show you the guts and low-level details. I also omitted the code for Zap and Zon terminal which in their turn use corresponding communication objects as well.

And now I’ll describe the problem which arose. The thing is that bank terminals are different. The ZonTerminal is a black-box solution which physically is a box which on its own works with credit card readers. Credit card readers are those devices which accept your card, read the chip or a magnetic stripe and dispense back a card back to you. So, ZonTerminal doesn’t expose API for interoperating with card readers, because the service application automatically sets all the necessary things up. At the same time, the other two bank terminals, “PdqTerminal” and “ZapTerminal” don’t take responsibility for interoperating with card readers automatically. On the contrary, they delegate this responsibility to a client, exposing API for interoperating with card readers.

So, in the first case (ZonTerminal), our application doesn’t need to do anything at all, while in the other two cases, our application has to show a window to POS-terminal maintenance engineers to provide the ability to set up the bank terminal devices properly.

Let’s look at the ViewModel class which is a presenter for that window which allows maintenance engineers to set up the bank terminal devices. The window has four buttons which allow to test if contact or contactless readers are on a certain port and to find them by scanning through all the available ports in the system.

[code lang=”csharp”]
public class CardReadersCommunicatorViewModel
{
public CardReadersCommunicatorViewModel()
{
}

public bool TestContactReaderOnPort(string port)
{
return false;
}

public bool TestNonContactReaderOnPort(string port)
{
return false;
}

public string FindContactReader()
{
return null;
}

public string FindNonContactReader()
{
return null;
}
}
[/code]

We need to pass in the CardReadersCommunicatorViewModel’s constructor a dependency which is capable of testing and searching for card readers on ports. Now ask yourself what would you do to solve the problem?

The straightforward way is to add four method signatures right into the IBankTerminal. Let’s do this and look at what will happen.

[code lang=”csharp”]
public interface IBankTerminal
{
…

bool IsContactReaderOnPort(string comPort);
bool IsNonContactReaderOnPort(string comPort);
string FindContactReader();
string FindNonContactReader();

…
}
[/code]

Ok, since we have three implementers we need to implement the just added API members. Everything will be fine with ZapTerminal and PdqTerminal.

[code lang=”csharp”]
public class PdqTerminal : IBankTerminal
{
private PdqTerminalServiceCommunicator _service = new PdqTerminalServiceCommunicator();

public event EventHandler PaymentCompleted;
public event EventHandler CancellationCompleted;
public event EventHandler TransactionCompleted;

public bool IsContactReaderOnPort(string comPort)
{
return _service.IsContactReaderOnPort(comPort);
}

public bool IsNonContactReaderOnPort(string comPort)
{
return _service.IsNonContactReaderOnPort(comPort);
}

public string FindContactReader()
{
return _service.FindContactReader();
}

public string FindNonContactReader()
{
return _service.FindNonContactReader();
}
}

public class ZapTerminal : IBankTerminal
{
private ZapTerminalServiceCommunicator _service = new ZapTerminalServiceCommunicator();

public event EventHandler PaymentCompleted;
public event EventHandler CancellationCompleted;
public event EventHandler TransactionCompleted;

public bool IsContactReaderOnPort(string comPort)
{
return _service.IsContactReaderOnPort(comPort);
}

public bool IsNonContactReaderOnPort(string comPort)
{
return _service.IsNonContactReaderOnPort(comPort);
}

public string FindContactReader()
{
return _service.FindContactReader();
}

public string FindNonContactReader()
{
return _service.FindNonContactReader();
}
}
[/code]

But what about ZonTerminal? ZonTerminal’s service doesn’t provide an API for communicating with card readers. Seemingly, we need to throw NotSupportedExceptions from the implemented members.

[code lang=”csharp”]
public class ZonTerminal : IBankTerminal
{
private ZonTerminalServiceCommunicator _service = new ZonTerminalServiceCommunicator();

public event EventHandler PaymentCompleted;
public event EventHandler CancellationCompleted;
public event EventHandler TransactionCompleted;

public bool IsContactReaderOnPort(string comPort)
{
throw new NotImplementedException();
}

public bool IsNonContactReaderOnPort(string comPort)
{
throw new NotImplementedException();
}

public string FindContactReader()
{
throw new NotImplementedException();
}

public string FindNonContactReader()
{
throw new NotImplementedException();
}
}
[/code]

Doesn’t this case remind you something? Something we’ve seen previously. Of course, this is a violation of the Liskov Substitution Principle. But what, we’re talking about the Interface Segregation Principle, aren’t we? Yes, we are, the thing is that as I told you earlier, all the principles are related to each other. Sometimes they have hidden relationships. In this particular case, we end up with the LSP violation as a consequence of ISP violation. If we stick with the current solution and request IBankTerminal, we will end up with the following code:

[code lang=”csharp”]
public class CardReadersCommunicatorViewModel
{
private readonly IBankTerminal _bankTerminal;

public CardReadersCommunicatorViewModel(IBankTerminal bankTerminal)
{
_bankTerminal = bankTerminal;
}

public bool TestContactReaderOnPort(string port)
{
return _bankTerminal.IsContactReaderOnPort(port);
}

public bool TestNonContactReaderOnPort(string port)
{
return _bankTerminal.IsNonContactReaderOnPort(port);
}

public string FindContactReader()
{
return _bankTerminal.FindContactReader();
}

public string FindNonContactReader()
{
return _bankTerminal.FindNonContactReader();
}
}
[/code]

we require the IBankTerminal interface as a parameter of the CardReadersCommunicatorViewModel’c constructor, one day, someone will pass the ZonTerminal into the constructor and the end user will get an exception after clicking on the testing or search button in the window.

So, if we want to avoid such unfortunate consequences, we need to acknowledge the fact that the IBankTerminal interface is too fat. It contains excessive API members.

Fixing the ISP Violation

The major and obvious refactoring technique which we usually apply to adhere to the ISP is that we create small isolated interfaces which represent well-defined concrete responsibilities. In this particular case, we need to segregate the responsibility which concerns the interoperating with card readers.

So, I’ll do that.

event EventHandler PaymentCompleted;
event EventHandler CancellationCompleted;
event EventHandler TransactionCompleted;
}

public interface IReadersCommunicable
{
bool IsContactReaderOnPort(string comPort);
bool IsNonContactReaderOnPort(string comPort);
string FindContactReader();
string FindNonContactReader();
}
[/code]

Now we should implement this new interface on our two models of bank terminal which actually can interoperate with card readers.

[code lang=”csharp”]
public class PdqTerminal : IBankTerminal, IReadersCommunicable
{
private PdqTerminalServiceCommunicator _service = new PdqTerminalServiceCommunicator();

public event EventHandler PaymentCompleted;
public event EventHandler CancellationCompleted;
public event EventHandler TransactionCompleted;

public bool IsContactReaderOnPort(string comPort)
{
return _service.IsContactReaderOnPort(comPort);
}

public bool IsNonContactReaderOnPort(string comPort)
{
return _service.IsNonContactReaderOnPort(comPort);
}

public string FindContactReader()
{
return _service.FindContactReader();
}

public string FindNonContactReader()
{
return _service.FindNonContactReader();
}
}

public class ZapTerminal : IBankTerminal, IReadersCommunicable
{
private ZapTerminalServiceCommunicator _service = new ZapTerminalServiceCommunicator();

public event EventHandler PaymentCompleted;
public event EventHandler CancellationCompleted;
public event EventHandler TransactionCompleted;

public bool IsContactReaderOnPort(string comPort)
{
return _service.IsContactReaderOnPort(comPort);
}

public bool IsNonContactReaderOnPort(string comPort)
{
return _service.IsNonContactReaderOnPort(comPort);
}

public string FindContactReader()
{
return _service.FindContactReader();
}

public string FindNonContactReader()
{
return _service.FindNonContactReader();
}
}
[/code]

Great. Now we can require the ICardReadersCommunicable interface in the ViewModel’s constructor.

[code lang=”csharp”]
public class CardReadersCommunicatorViewModel
{
private readonly IReadersCommunicable _readersCommunicable;

public CardReadersCommunicatorViewModel(IReadersCommunicable readersCommunicable)
{
_readersCommunicable = readersCommunicable;
}

public bool TestContactReaderOnPort(string port)
{
return _readersCommunicable.IsContactReaderOnPort(port);
}

public bool TestNonContactReaderOnPort(string port)
{
return _readersCommunicable.IsNonContactReaderOnPort(port);
}

public string FindContactReader()
{
return _readersCommunicable.FindContactReader();
}

public string FindNonContactReader()
{
return _readersCommunicable.FindNonContactReader();
}
}
[/code]

Great! There is no chance anymore that someone will pass an inappropriate instance which can’t work with card readers. And by the way, now it’s much more understandable what API members to use here, since we have a one-purpose interface here. Now a client of the interfaces should not be bothered by excessive API members thinking of their role. Now everything stands on its shelve.

By applying the ISP, we achieve the low coupling between methods which are different by their meaning and thus we achieve a high cohesion between them in segregated interfaces.

ISP Violation Example 2

In the previous case, the implementer of an interface itself knew too much, it knew what it should not that’s why it could not implement some members appropriately. So, the existence of a problem has already been obvious at the level of interface implementer.
Very often the problem goes deeper when the problem shows itself only at the implementer’s client level. Consider the following example.

[code lang=”csharp”]
[DataContract(Namespace = "")]
public class AppConfig
{
private AppConfig()
{
}

[DataMember(IsRequired = true)]
public string ServerId { get; set; }

[DataMember(IsRequired = true)]
public string ServerIP { get; set; }

[DataMember(IsRequired = true)]
public string ServerPort { get; set; }

[DataMember(IsRequired = true)]
public int LoggingSwitch { get; set; }

[DataMember(IsRequired = true)]
public int AppSkinId { get; set; }

[DataMember(IsRequired = true)]
public decimal Income { get; set; }

[DataMember(IsRequired = true)]
public decimal Outcome { get; set; }

[DataMember(IsRequired = true)]
public decimal TotalRevenue { get; set; }

public static AppConfig Config { get; private set; }

public static void Initialize()
{
using (Stream s = File.OpenRead("config.xml"))
{
Config = (AppConfig) new DataContractSerializer(typeof(AppConfig)).ReadObject(s);
}
}
}
[/code]

We have a configuration class which is implemented as sort of a singleton. Its constructor is closed and it only can be created via the Initialize method which deserializes an XML configuration file.

Not surprisingly we have a class which utilized that configuration file. Here we have the Report class which implements some business logic of reports generation:

[code lang=”csharp”]
public class Report
{
public string Generate()
{
return $"Income:{AppConfig.Config.Income}" + "\n" +
$"Outcome:{AppConfig.Config.Outcome}" + "\n" +
$"Total Revenue:{AppConfig.Config.TotalRevenue}";
}
}
[/code]

Currently it directly depends on the AppConfig class. Because of that, we can’t easily write a unit test for the Report class. What we only can do is to write an integration test which deals with xml configuration file, setting it up properly.

To fix the problem, we can abstract away the configuration class by introducing an interface. Let’s extract an interface:

[code lang=”csharp”]
public interface IAppConfig
{
string ServerId { get; set; }
string ServerIP { get; set; }
string ServerPort { get; set; }
int LoggingSwitch { get; set; }
int AppSkinId { get; set; }
decimal Income { get; set; }
decimal Outcome { get; set; }
decimal TotalRevenue { get; set; }
}
[/code]

Now we can request this interface to be passed in the constructor of the Report class.

[code lang=”csharp”]
public class Report
{
private readonly IAppConfig _appConfig;

public Report(IAppConfig reportsConfig)
{
_appConfig = appConfig;
}
public string Generate()
{
return $"Income:{_appConfig.Income}" + "\n" +
$"Outcome:{_appConfig.Outcome}" + "\n" +
$"Total Revenue:{_appConfig.TotalRevenue}";
}
}
[/code]

Great! Now we can write a unit test.

[code lang=”csharp”]
[TestFixture]
public class ReportTests
{
[Test]
public void Generate_ValidInput_GeneratesReport()
{
IAppConfig appConfig = new TestableAppConfig()
{
AppSkinId = 0,
Income = 10,
LoggingSwitch = 1,
Outcome = 100,
ServerIP = "192.168.0.1",
ServerId = "120888",
ServerPort = "8080",
TotalRevenue = 1000
};

Report sut = new Report(appConfig);
string report = sut.Generate();

Assert.AreEqual(
$"Income:10" + "\n" +
$"Outcome:100" + "\n" +
$"Total Revenue:1000",
report);
}
}

public class TestableAppConfig : IAppConfig
{
public string ServerId { get; set; }
public string ServerIP { get; set; }
public string ServerPort { get; set; }
public int LoggingSwitch { get; set; }
public int AppSkinId { get; set; }
public decimal Income { get; set; }
public decimal Outcome { get; set; }
public decimal TotalRevenue { get; set; }
}
[/code]

What’s wrong with this test? I set up all the properties, even those which are not required by the internal logic of the Report class. You could ask me why I indeed set all the properties, I could set only those which are required. Partly, you’re right, this would solve the problem of excessive code.

But imagine that there are tons of properties like in the real-world configuration file. Some of them even have similar names. Writing a unit test, would you be so sure that you have set all the properties required by the class under test? No, you wouldn’t. You’ll constantly see all that mess in the IntelliSense, asking yourself, whether that class requires that or another property to be set. The only way to get rid of that mess and make the code clearer and cleaner is to apply the Interface Segregation Principle.

Refactoring to Fix ISP Violation

To cure the disease, we should segregate the configuration interface. The Reports class should know only the part of configuration related to generating reports. Let’s extract that part into a separate interface.

[code lang=”csharp”]
public interface IReportsConfig
{
public decimal Income { get; set; }
public decimal Outcome { get; set; }
public decimal TotalRevenue { get; set; }
}
public interface IAppConfig
{
public string ServerId { get; set; }
public string ServerIP { get; set; }
public string ServerPort { get; set; }
public int LoggingSwitch { get; set; }
public int AppSkinId { get; set; }
}

public class TestableReportsAppConfig : IReportsConfig
{
public decimal Income { get; set; }
public decimal Outcome { get; set; }
public decimal TotalRevenue { get; set; }
}

Now we can request the IReportsConfig interface to be passed in the Report’s class constructor.

[code lang=”csharp”]
public class Report
{
private readonly IReportsConfig _reportsConfig;

public Report(IReportsConfig reportsConfig)
{
_reportsConfig = reportsConfig;
}
public string Generate()
{
return $"Income:{_reportsConfig.Income}" + "\n" +
$"Outcome:{_reportsConfig.Outcome}" + "\n" +
$"Total Revenue:{_reportsConfig.TotalRevenue}";
}
}
[/code]

Now, the Report class is aware of only those things which are relevant to the Report’s business logic. Let’s implement the unit test now:

[code lang=”csharp”]
[TestFixture]
public class ReportTests
{
[Test]
public void Generate_ValidInput_GeneratesReport()
{
IReportsConfig appConfig = new TestableReportsAppConfig()
{
Income = 10,
Outcome = 100,
TotalRevenue = 1000
};

Report sut = new Report(appConfig);
string report = sut.Generate();

Assert.AreEqual(
$"Income:10" + "\n" +
$"Outcome:100" + "\n" +
$"Total Revenue:1000",
report);
}
}

public class TestableReportsAppConfig : IReportsConfig
{
public decimal Income { get; set; }
public decimal Outcome { get; set; }
public decimal TotalRevenue { get; set; }
}
[/code]

Great! Now we don’t need to think of irrelevant stuff. The test is simple, clean and understandable.

Common Smells of Interface Segregation Principle Violation. Fixes and Related Patterns

ISP violation can be the root cause of LSP violation

In the first example, you’ve seen a smell which was similar to the violation of the Liskov Substitution Principle (LSP). We can refer to this smell as to “degenerate implementation of interface methods”. If a method which either overrides a method of a base class or implements a method inherited from an interface throws an exception, most likely NotSupportedException or it just does nothing what is called “degenerative implementation” that indicates that ISP may be violated. This is logical since there is a very high chance that a client of such a class doesn’t want to know about that method and doesn’t want to use it. At the same time, this is an indication of LSP violation, since such a class can’t act as a substitution for a base class or an interface. Sometimes, in such cases, the LSP violation is the root cause of the problem, but often the root cause is the violation of the ISP. So, you should study your particular case and figure out what causes the problem.

Too fat Interface

Another smell, which you’ve seen in the second demo can be described as the case when a client’s code references a class but only uses a small portion of its API. It obviously indicates that there is a low cohesion between such classes. This should suggest you that something is wrong here and you need to start the investigation of the problem. Often, you’ll find that the problem hides behind the too fat interfaces. To fix the problem, you have to properly segregate such an interface. Another sub-case here is that when you see a fat interface, but you don’t own it, you can’t change the interface because you can’t modify its source code. In that case, it might be useful to apply a Façade pattern. You’ve seen the application of this pattern in the SRP section. In this case, we can use Façade to narrow down the “width” of a fat class API.

If you have a fat interface and its API is not compatible with an interface on the client’s side when you try to use it, then you may find that there is also a possibility to apply the Adapter pattern. Firstly, let’s look at the Adapter pattern generally. What is the Adapter pattern?

According to the Gang of Four book, adapter pattern is intended to “Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces”. The picture above demonstrates a case when an adapter can be applied. Imagine that at first, we have the Client which depends on the Fighter interface. On the other side, we have the Wizard class which exposes three members incompatible with the Fighter interface. If we want to use the Wizard through the Fighter interface, we need to introduce a WizardAdapter which implements the Fighter interface and internally uses the Wizard, it adapts it.

In our case, when we talk about the Interface Segregation Principle, we don’t have a classic problem when an adapter is usually applied, because we don’t deal with incompatible interfaces. In our case, interfaces are not incompatible, one is just too fat for another. Nevertheless, the adapter pattern can also be applied in our case as well.

Let’s look at the code which demonstrates the case of applying the Adapter pattern in order to adhere to the ISP. I didn’t come out with a real case, so I’ll just show you a completely synthetic example.

[code lang=”csharp”]
public interface IWideInterface
{
void A();
void B();
void C();
void D();
}

public interface INarrowInterface
{
void A();
void B();
}
[/code]

Here is the case. At first, you see that we have the IWideInterface which defines four methods, A, B, C, and D. The client’s code wants to use only methods A and B. To apply the Adapter pattern, we can define a separate INarrowInterface which defines only A and B methods. The adapter itself is going to implement that INarrowInterface while it accepts the IWideInterface instance in the constructor.

[code lang=”csharp”]
class Adapter : INarrowInterface
{
private readonly IWideInterface _wide;

public Adapter(IWideInterface wide)
{
_wide = wide;
}

public void A()
{
_wide.A();
}

public void B()
{
_wide.B();
}
}
[/code]

As the implementation of A and B methods, adapter just delegates the responsibility to the IWideInterface instance. The client’s code now can rely on the INarrowInterface, taking the instance in the constructor. We can pass in the adapter instance and the client will get the access only to methods A and B.

[code lang=”csharp”]
//needs to use only A and B
class Client
{
private readonly INarrowInterface _narrow;

public Client(INarrowInterface narrow)
{
_narrow = narrow;
}
}
[/code]

This is how the Adapter pattern can be applied to adhere to the Interface Segregation Principle.

There is another tricky case related to the Adapter pattern. Let’s say we have a class Persister which is directly used by many clients:

[code lang=”csharp”]
public class Persister
{
public void SaveToFile(string file, string content)
{

}

public void SaveToDb(string connectionString, string content)
{

}
}
[/code]

And now let’s say new clients require a new method in the Persister and they will depend only on that method. Then we can do the following:

[code lang=”csharp”]
public interface INewPersister
{
void SaveToCloud(string connectionString, string content);
}

public class Persister : INewPersister
{
public void SaveToFile(string file, string content)
{

}

public void SaveToDb(string connectionString, string content)
{

}

void INewPersister.SaveToCloud(string connectionString, string content)
{
}
}
[/code]

Now old clients can use the Persister as they used before and they will not see the new method. While new clients will see only the new method. This implementation of the interface is called – “the explicit implementation”. You can call such a method only through the interface:

[code lang=”csharp”]
class PersisterClient
{
void Save()
{
Persister p = new Persister();
//doesn’t compile
//p.SaveToCloud("", "")

INewPersister np = new Persister();
np.SaveToCloud("", ""); // compiles
}
}
[/code]

That’s all about it.

Don’t forget that the general way of fixing a problem with a fat interface is to create a narrower interface with only absolutely required methods in it, then have the fat interface implement your new interface and then use that new interface in the client’s code which don’t need to know about irrelevant API members of a fat interface. This is exactly what we did in the second refactoring demo while fixing the problem with a configuration.

And the last point here I want to address is that you shouldn’t crush a whole class-level interface into multiple single-method interfaces just because this will make the ISP violation impossible. Apply the refactoring techniques only when you feel that there is a technical debt starts to appear here and there or if a technical debt hasn’t started to spread yet but you know for sure that it will if you don’t fix the ISP violation.

The last tip I want to say about, concerns the dependency management at a binary level. So, the tip is that it is better whenever possible to keep the interface within the client’s assembly. It makes easier to change the interface if something goes wrong. A client will be able to change the interface exactly how it wants instead of rolling out any adapters.

Conclusion

The principle we discussed throughout this post was the Interface Segregation Principle or ISP in short. The ISP has a simple definition: “Clients should not be forced to depend on methods they do not use.” So, this definition implies that you have to strive to create small, cohesive and focused interfaces.

Of course, different clients can use only a subset of API members they depend upon, unless that API start to grow transforming into a very fat interface with unrelated members to each other or when similar but different methods appear to satisfy the requirements of different clients.

A typical way of violation you saw was when an interface was too broad what led to some smells like:

implementers throw NotImplementedException
clients have to see all the mess in the IntelliSense thinking of what they actually need to use.
As we discussed, there are several ways of dealing with ISP violations:
sometimes it is just enough to extract a separate interface from a fat one and use it where appropriate
sometimes you need to come out with a Façade which hides irrelevant API members
sometimes you need to apply an Adapter pattern especially if you don’t own the fat interface and thus you can’t modify its source code

Intelligent adhering to the Interface Segregation Principle makes an application easier to maintain what is extremely valuable especially in the long term.

Abusing ISP, you can end up with tons of too small interfaces what makes them harder to use by all clients. This is a smell known as Anti-ISP.

That’s all for the ISP. That was an interesting investigation. But there is another principle waiting for us, the “Dependency Inversion Principle”.

SOLID Principles: Liskov Substitution Principle (LSP) In Practice

EngineerSpock — Wed, 26 Dec 2018 17:10:28 +0000

LSP Definition

The official definition from Barbara Liskov sounds like this:

“If S is a subtype of T, then objects of type T may be replaced with objects of type S, without breaking the program” – B. Liskov.

It’s not very hard to grasp what this definition means but I’ll quote the definition of LSP from the book of Uncle Bob “Agile Principles, Patterns, and Practices in C#” just in case. We find there the following definition of the Liskov Substitution Principle:

“The Liskov Substitution Principle states that Subtypes must be substitutable for their base types.”

By the way, Barbara Liskov is a scientist who described this principle in 1988. Let’s try to clarify what LSP means for developers in practice. What does it mean to be substitutable for a class? Let’s pretend that we have a client which uses the API of interface B.

There are two implementors of that interface B. It is implemented by classes A and C. Class C can be considered substitutable for class A if the client doesn’t observe any difference using the class C instead of A. From the client’s perspective, a client shouldn’t experience different behavior using different inheritors of the same base class or an interface.

Actually, the LSP is strongly related to how object-oriented languages allow us to use inheritance.

If class B inherits from A, then we can use B as A but we can’t use A as B. Thus, clients of A can use both A and B even if they know nothing about B. This is basics of polymorphism. Despite that this is basics, developers all the time violate the logic of such a relationship. By the way, as a remark, I want to remind you that it’s not necessary to have such a mechanism as the inheritance to model such relationships between objects. In dynamically typed languages, we use the so-called Duck Typing. If a bird swims like a duck, it quacks like a duck then I call that bird a duck. That’s why the term “Duck Typing” appeared. Dynamically typed languages don’t know if we’re allowed to call a certain method or not. The runtime checks if an object can respond to a message. By saying “message”, I mean a call to a method since in Dynamically Typed Languages it’s better to say “send a message” rather than “call a method.” Ok, let’s get back to the main topic.

LSP Violation

There are two ways of breaking the substitutability:

Violating a Contract
Violating Covariance\Contravariance

For a significant number of developers, it’s unclear what does it mean, so it requires further clarification. Without understanding these fundamental concepts, you’ll not be able to design types which don’t violate LSP, sooner or later you’ll bump into the horrible problems caused by an LSP violation. So, keep patience and let’s discuss a little bit the notion of contracts.

Contracts

Programming to Contracts was elaborated by Bertrand Meyer. In his classic book “Object-Oriented Software Construction”, he described the advantages of programming to contracts. He even came out with a whole new language called “Eiffel” which was built with programming to contracts in mind.

So, what is a contract? Many developers mix the notions of an interface and a contract. This statement becomes more convincing with the fact that in WCF we treat interfaces and contracts equally. In WCF, a service contract can only be represented by an interface. In the real world, including real world outside of programming, contracts have some semantic payload. Usually, they determine some kind of relationships between people, rights, objects and so on. Interfaces have no semantic payload. They determine nothing except signatures. But signatures don’t bear any significant semantic payload. An interface represents just a shape. Thus, interfaces are not contracts.

Here is an example of a contract provided by Krzysztof Cwalina:

[code lang=”csharp”] public abstract class CollectionContract : IList {
public void Add(T item) {
AddCore(item);
count++;
}

public int Count {
get { return count; }
}

protected abstract void AddCore(T item);

private int count;
…
}[/code]

This contract says that when an item is added to the collection, the Count property is incremented by one. In addition, this contract is locked for all subtypes.

A contract of a method constitutes of the following parts:

Acceptable and unacceptable input values or types, and their meanings
Return values or types, and their meanings
Error and exception condition values or types that can occur, and their meanings
Side effects
Preconditions
Postconditions
Invariants

From the learning perspective, we are mostly interested in Preconditions, Postconditions, and Invariants. Preconditions of a function are the set of requirements a function applies to the input parameters and sometimes the state of the object to which that function belongs.

I have a simple example from my own practice. It is, of course, simplified and presented in a form of a skeleton for the sake of simplicity.

[code lang=”csharp”] public interface IBankTerminal1PaymentGateway
{
uint ProcessPayment(decimal amount);
}
public interface IBankTerminal2PaymentGateway
{
uint ProcessPayment(decimal amount, string uniqueId);
}
public interface IBankTerminal
{
int ProcessPayment(decimal amount, string uniqueId);
}
public class BankTerminal1 : IBankTerminal
{
private IBankTerminal1PaymentGateway _gateway;

///Response Code. Always >= 0
public int ProcessPayment(decimal amount, string uniqueId)
{
//doesn’t require uniqueId at all
return (int)_gateway.ProcessPayment(amount);
}
}

public class BankTerminal2 : IBankTerminal
{
private IBankTerminal2PaymentGateway _gateway;
public int ProcessPayment(decimal amount, string uniqueId)
{
if (string.IsNullOrWhiteSpace(uniqueId))
{
throw new ArgumentException("A client must provide a unique ID for BankTerminal2");
}
return _gateway.ProcessPayment(amount, uniqueId);
}
}[/code]

Here we have two different bank terminal models. Both models derive from the IBankTerminal interface which defines the ProcessPayment operation.

These terminals share a significant amount of business logic and they have very similar interfaces, so developers decided to join them by introducing that IBankTerminal interface. Unfortunately, both terminals have their own payment gateways with different interfaces. One requires a uniqueId to be generated by a client, while another doesn’t. To make the API universal, developers just rolled out a single method with two parameters.
The implementation of the first terminal just ignores the second parameter, while the second checks the uniqueId and if it’s null or white space, it throws the ArgumentException.
A client doesn’t expect such a behavior working with the base class. This happens because the second inheritor strengthens the preconditions. The first terminal accepts the uniqueId which can be equal to any value, no restrictions were applied.
The corollary is that a client has to be aware of different behavior of these bank terminals. Those clients who worked with the first terminal would not expect any exceptions working with the second one passing null as a unique id.

The overall idea is that by weakening postconditions, inheritors extend the possible outcome from a function. As a result, clients face unexpected situations or they, in the end, have to understand different cases and treat them in a specific way.

You can write contracts on the .NET platform in C# with a special library called “Code Contracts”, not surprisingly. Using code contracts, you can harness the power of static code verification on correctness. Due to some practical problems and problems related to the poor implementation of the “Code Contracts” library, it’s not a very popular approach nowadays. For example, Code Contracts work very slow on big solutions. And this is only one of the reasons. This library is out of the scope of the course, so if you’re interested in “Code Contracts” you can just google for it.

Another problem I want to demonstrate is related to the violation of invariants on a classic example in the next lecture.

Violation of Invariants

Let’s consider a classic example of LSP violation. I love this example because of two reasons. The first one is that it actually demonstrates the LSP violation and this reason is obvious and the second reason is that it shows that Object-Oriented Programming often can’t directly map the relationships between objects in the real world into the same model of relationships between them in code.

A great number of developers think that writing code in OOP language, they’re modeling real-world domain problems. And partly this is true. But the real-world relationships between objects sometimes can’t be modeled directly in OOP language. Here is one of the naïve OOP statements: “child classes implement IS-A relationship with base classes”. For example, Dog is an Animal. Cat is an Animal. So, we can create three classes. Animal is the base class and the other two (Cat and Dog) are inheritors. Unfortunately, sometimes this kind of design doesn’t work as expected and you’ll see this in a minute.

So, let’s reflect the relationships between two real-world notions in code. We want to implement a Rectangle and Square, being able to calculate their areas. I’m sure you’ll agree with me that in the real world, Square is a special case of Rectangle. It’s obvious because Square is Rectangle with equal sides.

So, we can write the following:[code lang=”csharp”] public class Rectangle
{
public int Width { get; set; }
public int Height { get; set; }
}

public class Square : Rectangle
{
}[/code]

I created the Rectangle class which has two properties: Width and Height and the Square which inherits from the Rectangle class. Separately I will create the class which is responsible for calculating areas of that shapes.

[code lang=”csharp”] public class AreaCalculator
{
// or maybe it’d be better to multiply Widths?
public static int CalcSquare(Square square) => square.Height * square.Height;
public static int CalcRectangle(Rectangle square) => square.Height * square.Width;
}[/code]

Looks fine from the first sight. I’ll pretend that I’m a client and I want to create two shapes and calculate their areas. For that, I’ll implement the Main method where all the things will happen.

[code lang=”csharp”] class Program
{
static void Main()
{
Rectangle rect = new Rectangle() { Width = 2, Height = 5 };
int rectArea = AreaCalculator.CalcRectangle(rect);
Console.WriteLine($"Rectangle Area = {rectArea}");

Rectangle square = new Square() { Height = 2, Width = 10 };
int squareArea = AreaCalculator.CalcRectangle(square);
Console.WriteLine($"Square Area = {squareArea}");
}
}[/code]

Pay attention to this:

[code lang=”csharp”] Rectangle square = new Square() {Height = 2, Width = 10 };[/code]

Wait a minute. What the hell is this? How a Square can contain sides of different length?
I hope that it’s obvious that something is wrong here with the API of Square. Square allows to set different length to Width and Height.

This design clearly violates the Liskov Substitution Principle. Square is not substitutable for Rectangle. Rectangle implements the invariant which states that width and height could be of different length. Square has to implement another invariant which states that Width and Height have to be equal. I intentionally omit that actually they also have to be greater or equal to zero.
There is another problem is hiding here. Most likely you would need to create methods which take rectangle as a parameter and implement some business logic. In case of calculating the area, such a method could look like this.

[code lang=”csharp”] public static int CalcArea(Rectangle rect)
{
if (rect is Square)
{
return rect.Height * rect.Height;
}
else
{
return rect.Height * rect.Width;
}
}[/code]

This method checks the type inside the method and run the appropriate calculation algorithm.
What do you think? Is it a good way to solve the problem of LSP violation? Doesn’t this fix resemble you something we’ve seen previously? Yes, indeed, this is a violation of the Open/Closed principle. This method is open for modification. What will happen if we introduce a new shape? Correct, we will have to modify that switch-statement. This example of LSP violation is a hidden violation of OCP.

Remember that inheritors can require less and guarantee more but not vice-versa. The smell which we observe here is also called “Refused Bequest”. Why at all the problem arise in the way it actually arises here? Were we wrong saying that a square is a special case of a rectangle? No, we were right, this is ridiculous to think what we were wrong. Any child knows that a Square is a subtype of a Rectangle. So why we face this problem directly modeling such a relationship between square and rectangle abstractions?

The answer is quite irritating; the thing is that the programming code just represents the concepts of square and rectangle. The class Rectangle is not a rectangle, and the class Square is not a Square, they are just representatives. Everything is fine actually, the thing is that representatives in the real world also don’t share the relationships between things they represent. So, how can we fix such a poor design?

Refactoring to Remove LSP Violation

Obviously, we need to make impossible to set different length of sides for a square to fix the problem. For now, the expectations of the square’s clients are broken. The AreaCalculator class now demonstrates that there is a problem of separated data and behavior. The calculation algorithms are separated from the Rectangle and Square classes which own the data required for calculations. The AreaCalculator can’t exist without Rectangle and Square, so why the behavior was moved away from Rectangle and Square? Rectangle and Square for now obviously lack cohesion. To cure the decease, we as always should construct proper abstractions. What we want to abstract away is the business logic of calculating the area. Each shape has its own algorithm of calculation the area. It is much better to make behavior shared rather than data.

Let’s abstract away the CalculateArea method by introducing the IShape interface.[code lang=”csharp”] public interface IShape
{
int CalculateArea();
}[/code]

I want the Rectangle and Square to inherit from the IShape implementing their own algorithms.[code lang=”csharp”] public class Rectangle : IShape
{
public int Width { get; set; }
public int Height { get; set; }

public int CalculateArea() => Width * Height;
}

public class Square : IShape
{
public int SideLength { get; set; }

public int CalculateArea() => SideLength * SideLength;
}[/code]

Square now defines its own property named SideLength. Now a client can’t misuse their API. In case of Rectangle, calling to CalculateArea, a client will get the area of a Rectangle, while in case of Square, a client will get the area of a Square. The client can’t set different length of width and height to a square.

More Examples of LSP Violation

Variance

We omitted the discussion of a very important topic – variance. Variance is a very complicated concept, so we’re going to only touch this topic despite that it is related to the LSP.

Variance is the notion that describes the types compliance. It branches out to two notions: covariance and contravariance.
Assuming the type A can be cast to type B, type X is covariant in case X can be cast to X.

Algorithms and Data Structures in C#: Complete Tutorial

EngineerSpock — Mon, 03 Dec 2018 13:22:28 +0000

Why learn about data structures and algorithms?

Algorithms and data structures constitute the fundamentals of programming.

Good understanding of algorithms and data structures is one of the most important requirements for a great number of work positions. You’ll have to solve many problems related to algorithms and data structures at coding interviews. Indeed, you can live without an understanding of algorithms and data structures, in general. However, you can do that until you face a real problem which requires to choose the right data structures and implement custom algorithms. If you haven’t ever faced such problems, believe me, this is just a matter of time. One day, you’ll face such a problem and if you don’t understand algorithms and data structures in depth, you’ll feel yourself ashamed and helpless. You’ll be stuck.

If you’re not good at algorithms and data structures, you’ll never pass a coding interview in a decent company. Almost all the companies prefer to hire those developers who have a good understanding of algorithms and data structures, remember that. Do not delay the study of fundamental concepts.

Better hardware is not a solution for all the performance-related problems. Sometimes, you need to write software for very slow devices. And that very often depends on the budget of a customer, by the way, so you don’t have a control over it.

You’d better understand what’s going on under the hood at least one level in-depth. Indeed, if you don’t understand how List works, sometimes you’ll make sub-optimal or completely wrong decisions.

Why this course?

You may ask me “why should I take exactly your course?” And here is my answer:

This course is a comprehensive tutorial which covers a great number of topics
I tried to do my best to make this course not dry
This course concentrates not only at algorithms and data structures in general but it uncovers the internals of data structures and algorithms built-in .NET BCL (.NET Core’s BCL is the same regarding fundamental data structures and algorithms)
This course is practical with exercises and solutions
This course will definitely help you to pass technical interviews
This course is made by a professional software developer with more than 10 years of real-world experience
and many other reasons

What’s in the Course?

For now, the course covers:

Introduction to Algorithms and Data Structures: what is a data structure, abstract data type and what’s the difference between these notions. What is an algorithm and why they are important to us?
Introduction to Algorithm Analysis: determine how long will a program work, build a log-log plot, approximations, order of growth (Big-O notation), memory consumption
Arrays: arrays in C#, arrays in memory, time complexity of operations on arrays
Sort Algorithms: bubble sort, selection sort, insertion sort, recursion, shell sort, merge sort, quick sort, stability of sort algorithms
Lists: List built-in .NET BCL, nodes, linked list including singly and doubly linked lists, linked list built-in .NET
Stacks: theory and practice; stack based on array, stack based on a linked list, stack built-in .NET
Queues: theory and practice; queue based on array, circular queue, queue based on linked list, queue built-in .NET BCL
Search Algorithms: linear search, binary search (more will be added soon)
Immutable Collections: immutability and memory pressure, immutable stacks and queues, immutable list, immutable sets, immutable dictionaries, builders in immutable collections
Other big sections upcoming soon including: Trees, Heaps, Hashtables

You, as a reader of my blog, are eligible for taking this course just for 9.99$ via the following link: https://bit.ly/2Ubm6B5

Take this course now and you’ll be satisfied! Don’t forget that Udemy provides 30-day money back refund policy, so if you don’t like the course, you just click on a couple of buttons and get your money back!

Introduction to Selenium

EngineerSpock — Tue, 30 Oct 2018 18:47:26 +0000

What is Selenium

Selenium is a portable software testing framework for web applications. Basically, it automates browsers what in other words means that it simulates how human beings interact with browsers, e.g. click on buttons, select check boxes, type in some text and so on.

There are two major ways of using the power of Selenium:

Selenium IDE – There is Selenium IDE which, in short, allows us to click on the record button, do all the actions in the browser and then replay them by the means of the same IDE. In other words, it allows recording automation test scripts. IDE will generate scripts based on our actions in the browser. Though it allows editing such generated scripts manually, there are no problems with that.
WebDriver – is a framework which enables writing UI-tests manually in code. Manually written tests are more maintainable comparing to generated scripts with ugly member names and it, of course, implies that there will be a full power of a programming language such as C# at your disposal.

Testers very often rely on Selenium IDE when they need to automate some UI-tests, usually due to the lack of programming skills, while programmers more often rely on the WebDriver since it gives more freedom and power. In this course, we’re going to talk about the WebDriver 99% of the time.

In general, the WebDriver API can be consumed by different languages such as C#, Java, Ruby etc. So, we’re going to write code in C# referencing Selenium WebDriver NuGet packages. Roughly speaking, there are as many WebDriver API implementations as there are browsers. We’re going to work with the Chrome implementation. And, finally, a specific WebDriver API implementation directly manages the browser. Modern Selenium 3 WebDriver directly calls Web Browser commands rather than fiddling around some javascript code to manage browser and elements on a page. So, we need three components to work with Selenium:

Web Browser installed
Web Driver which is really a web server sending commands to a browser. Each browser has its own driver because each browser exposes different commands
A script which can be written as I already said in different programming languages such as Java or C# or Ruby.

So, this is how the overall process works. In short, with the power of WebDriver, you can do literally anything you want:

Navigate to any URL
Resize the Browser window
Click on any button
Select any element
Upload files
Download files
and so on

Key Elements of Selenium

The key parts when we work with Selenium are:

WebDriver – which is the most important class responsible for managing a browser. 99% of WebDriver API calls go through the WebDriver object.
WebElement – another class which encapsulates any element on a web page such as a button, link or an input element. It provides methods for manipulating elements, clicking on them, sending a text to them and so on.
By – a class which represents an extremely important notion which is called a “locator”. It encapsulates information used by WebDriver for searching for a particular element on a page.

Writing First Automation Example

Let’s write our first automation example without digging into details too much. Visit the following link: https://www.ultimateqa.com/simple-html-elements-for-automation/

You’ll see three buttons and a link. Here is the picture:

I drew black boxes around elements that we want to click on. As I mentioned earlier, there is a concept of a “locator” that is used for searching the elements. Let’s talk about locators a bit.

Selenium Locators

The most important thing you need to learn to successfully use Selenium concerns the problem of locating web elements. To search for an element, you need to provide the so-called locator to a web driver. Locators are represented by the By class. We have eight ways of defining a locator.

Assuming that a page has the following button:

[code lang=”html”]

Writing the First Acceptance Test with SpecFlow

EngineerSpock — Mon, 22 Oct 2018 14:48:47 +0000

To write acceptance tests using SpecFlow, we need to properly set up the environment and a testing project.

At first, we need to install a SpecFlow extension for Visual Studio. We need it because SpecFlow integrates into Visual Studio allowing us to easily format features and scenarios, generate corresponding code and other things. The installation process is straightforward. The only thing is that it will require from you to restart Visual Studio.

Let’s assume that I have a class which implements the TicTacToe (Crosses and Noughts) game with the following API:

[code lang=”csharp”] public class Game
{
public void MakeMove(int index);
public Winner GetWinner();
}[/code]

To write an acceptance test, create a separate project (class library). Install the SpecFlow NuGet package. Apart from that, we need to install a NuGet package for integration of SpecFlow and a unit testing framework which will be used to run tests and write assertions. In my case, I’ll install a package for integrating SpecFlow with NUnit. This package automatically installs the NUnit package to the project since it depends on it. Now we are ready to go.

At first, we need to add a spec flow file. Go to the project and add a new item, search for SpecFlow section, select it and select the “Feature File in English”. It’s hard to write high-level business requirements and scenarios for such a simple game, so we will pretend a bit.

Let’s describe a feature.

Feature: TicTacToe Play Game

In order to play a TicTacToe game

As a gamer

I want to be able to put crosses or zeroes and determine a winner

Let’s describe at least one scenario.

Scenario: Play game
       Given I started a new game
       When I put three crosses in a row       
       Then I should win

This is the simplest form of a scenario. We can pass tables of values or constants to code from scenarios. SpecFlow supports many cool features. To execute such a description, you need to generate C# code and implement the test. To generate the code, click on the right mouse button somewhere in the feature file and click on the “generate step definitions”. In the popped up window, click “generate a file”. The following file will be generated:

[code lang=”csharp”] [Binding] public class TicTacToePlayGameSteps
{
[Given("@I started a new game")] public void GivenIStartedANewGame()
{
}

[When(@"I put three crosses in a row")] public void WhenIPutThreeCrossesInARow()
{
}

[Then(@"I should win")] public void ThenIShouldWin()
{
}
}[/code]

Here you can see the generated testing class. SpecFlow applied special attributes like Binding and Given, When and Then for the steps.

Let’s implement the test.

Given, when, and then steps directly map to the corresponding arrange-act-assert triplet. So, at the given step we need to arrange the object under test. Let’s do this.

[code lang=”csharp”] [Binding] public class TicTacToePlayGameSteps
{
private Game _game;
[Given("@I started a new game")] public void GivenIStartedANewGame()
{
_game = new Game();
}
}[/code]

At the When step, we should perform actions. Let’s implement it.

[code lang=”csharp”] [Binding] public class TicTacToePlayGameSteps
{
private Game _game;
[When(@"I put three crosses in a row")] public void WhenIPutThreeCrossesInARow()
{
_game.MakeMove(1); //1
_game.MakeMove(4);
_game.MakeMove(2); //2
_game.MakeMove(5);
_game.MakeMove(3); //3
}
}[/code]

The combination of crosses put in the fields indexed first, two and three should lead to winning. Let’s verify this fact at the Then step.

[code lang=”csharp”] [Binding] public class TicTacToePlayGameSteps
{
private Game _game;

[Then(@"I should win")] public void ThenIShouldWin()
{
Assert.AreEqual(Winner.Crosses, _game.GetWinner());
}
}[/code]

After rebuilding, Visual Studio should detect the acceptance test and allow to run it as a regular unit test. This is how you can create executable documentation easily with the power of SpecFlow. I bet you see the difference between acceptance testing a unit testing. Acceptance tests are understandable for domain experts, while unit tests are not. Want to fill in the gap between domain experts and programmers, then learn SpecFlow and implement use cases in high-level business-readable acceptance tests.

I have a video course:
“Automate Application with SpecFlow and Selenium WebDriver in C#”.
You, as a reader of my blog, are eligible for taking a maximum possible discount.

Acceptance and UI Testing with SpecFlow and Selenium

EngineerSpock — Mon, 22 Oct 2018 14:09:54 +0000

Pyramid of Tests

Basically, tests can be divided into three major groups:

unit tests
integration tests
acceptance tests

Unit tests are those tests which verify the behavior of a unit under test in isolation. That’s why when a unit under test has dependencies, we often mock them or in other words replace by special test doubles. Unit tests are great, and the majority of tests should belong to this type of tests. This is because this type of tests is hard to break and easy to run (of course, if they are written in a good style).

On the contrary, integration tests verify the behavior of either a part of a system or a whole system. Saying “part of a system”, I mean any significant part which consists of a few units which communicate with each other. Integration tests are brittle, easy to break, hard to maintain and slow. The only one benefit is that they verify how many components interact with each other without any mocks. Components are going to be tested in the environment close to the production’s environment. That’s why integration tests can detect defects undetected by unit tests.

Acceptance tests verify the software from the user’s point of view. Acceptance tests are expressed in a regular English language. Yes, indeed, they allow customers to write tests in plain English just in a formal syntax. Of course, customers are not allowed to write novels, but writing acceptance tests is much easier than writing unit tests for customers. This way of writing tests allows to meet the requirements written by a customer himself. We will look into an example or a few of examples of how to write such tests in a corresponding section.

You should understand that each type of tests has its own pros and cons. Integrations tests are not better than unit tests or vice-versa. A wise approach to testing is to use different types of tests. Moreover, we usually end up with a pyramid of tests. Here is the pyramid:

There is no silver bullet regarding the right balance of different types of tests. That balance depends on the type of software you’re working on.

Integration and UI Testing

The most significant part of the pyramid consists of unit tests, then integration and acceptance tests go.

Integration tests verify the behavior of either a part of a system or a whole system. They verify how many components interact with each other without any mocks. Components are going to be tested in the environment close to the production environment. That’s why integration tests can detect defects undetected by unit tests. There is also a notion of UI tests. What are UI tests?

Remember that UI tests are integration tests in nature. UI Tests allow to drive the executing of an application by automatic actions performed on the UI. It allows saving much time since it doesn’t require manual testing. We just write code which performs all the actions on the UI. Assertions in UI tests verify what UI shows to users. Integration tests are not comprised of only UI tests. UI tests are only a part of the suite of integration tests.

Why Write Automated UI Tests?

Why we might want to write automated UI tests at all? The major benefits of writing UI tests are related to the benefits of any integration tests since UI tests are integration tests (in principle).

So, here are the main benefits of writing UI tests:

UI tests can play a role of end-to-end tests which bring into play literally all the code layers of the application.
UI glitches – UI tests can catch any UI-glitches which is very important for providing the best user experience. For example, UI tests can catch such bugs as a help message doesn’t appear, a button gets disabled or enabled inappropriately and so on.
UI tests reduce (sometimes down to zero) the amount of work that needs to be done by manual testers.
In the case of Web UI tests, you’ll be able to run the same tests against different web browsers such as Firefox, Chrome, Opera and so on. I bet you understand what value it brings to the table, especially if you’re a web developer.

I mentioned that UI tests can reduce the amount of work that needs to be done by manual testers. Actually, teams often try to compare automated UI testing versus manual UI testing. Let’s mark out some benefits of automated UI tests over manual tests:

Automated UI tests run faster than manual tests and because of that, they provide feedback much faster. They also can be run at any point in time just by a couple of clicks.
Executing a suite of automated UI tests, you ensure the fullness of UI tests while human beings very often forget to perform some tests even when they work with a check-list.
Automated UI tests very often serve as a mechanism which is complementary to what manual testers do. I would say, that if your development team has manual testers, the software developers or sometimes even testers on their own can write all the automated UI tests which are simple to implement, leaving all the complex UI tests which are hard to implement in the code for manual execution. In such a case, UI-tests will free up human testers and allow them to use their skills more efficiently performing the so-called exploratory testing. Human beings are pretty smart and can discover such slick bugs that can’t be discovered automatically.

What is an Acceptance Test?

In general, acceptance tests are business readable automated tests. Why do we need them? There are several benefits of writing acceptance tests.

The first benefit is to bring people from the problem domain. In 99% of cases, people from the problem domain are not software engineers and know nothing about unit tests and coding process in general. They can only express the requirements in the natural language. So be it, acceptance tests allow non-technicians to write tests in the natural language. Not in the completely arbitrary style. There is a special form for writing scenarios. So, the first goal is to reduce or completely remove the gap between software developers and specialists from the problem domain. Another benefit is that acceptance tests form the documentation. And what even better, they form executable documentation. That documentation reflects:

what features does the system have
how do those features work
what different usage scenarios does the system support

The good thing is that tests reflect the needs of the end users what means that developers can build the right thing and build it right. Indeed, acceptance tests are electronic incarnation of use cases written on cards within the Agile.

Another benefit is that acceptance tests always reflect current requirements. Either we keep acceptance tests always updated or ditch the whole idea completely. There is no something in between these states. Acceptance tests should always stay in sync with the actual code. Acceptance tests, as well as any tests, are backed up by a framework. The most popular framework to write and run acceptance tests is called SpecFlow.

Acceptance and UI-Automation Testing Frameworks

I would mark out the following UI-testing frameworks:

Selenium
Visual Studio Coded UI Test
TestStack.White

Selenium is a framework for testing web-UI while VS Coded UI Test allows writing UI-tests both for web-UI and desktop-UI. Selenium and VS Coded UI Test frameworks record all your actions and generate code which replays them. Selenium, however, supports another approach which is more suitable for developers and that approach allows to write tests manually. Such tests, in general, are more customizable, readable, and maintainable.

TestStack.White doesn’t allow to record actions and replay them. It allows writing UI-tests manually in code. This approach takes more time, but it allows to write, as I already said, human-readable and well-maintainable code while the generated code is hard to understand and maintain. TestStack.White is faster than VS Coded UI Test roughly five times being tested on a WPF application.

SpecFlow is a mature framework for writing acceptance tests. SpecFlow allows us writing special features files in a semi-formal language called Gherkin. We express business requirements and use cases in feature files. A SpecFlow extension that we need to install in Visual Studio allows generating executable C# code from the feature files. That code automatically gets bound to feature scenarios. In the generated code we write actual testing code and write assertions with the power of almost any unit testing framework we want to.

We will look into SpecFlow and Selenium further in this series of posts.

I have a video course “Automate Application with Specflow and Selenium WebDriver in C#”.
You, as a reader of my blog, are eligible for taking it with a max possible discount.

Complete Practical LINQ Tutorial in C#

EngineerSpock — Wed, 12 Sep 2018 08:46:00 +0000

LINQ to Entities, LINQ to Objects, LINQ to XML,
Functional Programming and LINQ

Extension methods were introduced in C# 3 and since then became an indispensable part of the .NET platform. That enormously powerful feature allowed to build a whole framework built upon it called LINQ or Language Integrated Query. I’ve seen many code bases which avoid using LINQ and rely on the old procedural style of programming. If you still feel uncomfortable with LINQ or you want to improve your understanding of LINQ, then this course is for you. As you might know, LINQ was inspired by functional paradigm and F# in particular. So, this course is not only about LINQ but about the fundamentals of functional programming as well.

This course covers:

The basics of LINQ: extension methods, the idea of pipelining, IEnumerable, implementing our own extension, query syntax, pitfalls of LINQ operations, how to alter a list
Generating data streams: Enumerable class and its main operations, implementing your own extension which generates a stream of data
Filtering, Ordering, Projecting: Parsing a CSV file, ThenBy, First, Last, Single, TakeWhile, SkipWhile, Any, All, Contains, SequenceEqual, Select and SelectMany
Joining, Grouping, Aggregating: Join, Group, GroupJoin, Zip, Sum, Average, Min, Max
Conversions: OfType, Cast, ToArray, ToList, ToDictionary, ToLookup, AsEnumerable, AsQueryable
LINQ to XML: overview, generating XML from a collection, reading XML
EF and LINQ: Expression Trees, Inserting into and Reading from a database
Extendibility in C#: what is functional programming (FP), purity and side effects, extending IDisposable, general-purpose extensions, extending StringBuilder, Primitive Obsession

In short, this is a great course, so enroll right now and start learning LINQ and the fundamentals of functional programming just for 10.99$.

Double Your Coding Speed with Visual Studio and ReSharper

EngineerSpock — Wed, 12 Sep 2018 07:57:19 +0000

Learn how to speed up the coding process in bear Visual Studio 2017 and VS empowered by ReSharper (R#).

Modern integrated development environments or IDEs, in short, allows us to perform miracles. Why? Because we live in the twenty-first century and modern computers are so powerful that modern IDEs become indispensable assistants which can save us thousands of hours. A decade ago, no one could imagine how much powerful IDEs will become in the future. However, nowadays, developers are armed by superpowers such as deep static analysis, automatically performed refactorings, code fixes, super simple navigation, and many other things.

This is a developer without a powerful IDE.

Abject worm. Go and kill yourself against the wall.

Or become a real developer. Here is how a real developer looks like:

Want to become an iron developer? Then listen to me.

This course consists of two main parts. The first one concerns the features of a bear visual studio without any super-powerful plugins and it covers:

Navigate through the code base: how to select code, how to find code, camel humps in IntelliSense, navigating through the tabs
Edit and format the code base: deleting and removing code, formatting, commenting and applying refactorings
Run and debug your code: working with breakpoints, new features of a modern visual studio, different debugging windows
Code snippets: existing code snippets and creating custom code snippets
Extensions for Visual Studio: Color VS Output, NCrunch, PInvoke, .NET Portability Analyzer, Roslynator

The second part is dedicated to ReSharper (R#). ReSharper is one of the flagship tools developed by JetBrains. I need to warn you that R# is a paid tool but despite this fact, the majority of professional developers use it on an everyday basis. In my opinion, apart from programming fundamentals, R# is exactly that tool which makes you that guy from the picture:

R# is a Visual Studio plugin which empowers it by tons of refactorings, analytical features, fixes and a ton of other features. So, the second part is dedicated to R# and it covers:

Installing R#
R# Settings
Creating Code with R#
Exploring Code with R#
Refactoring with R#
Unit Testing with R#
R# Annotations

This is only an introduction to R#. I’ll update this course from time to time teaching you other cool features provided by R#.

Enroll and start learning how to double your coding speed in bear Visual Studio and Visual Studio empowered by R# for only 10.99$ right now!

Multithreading and Parallel Programming in C#

EngineerSpock — Wed, 25 Jul 2018 10:18:35 +0000

For the last two decades, computers became faster by increasing the number of CPU cores. However, the fact of having more cores itself doesn’t make a computer drastically faster if those cores are not used by software properly. We, as software developers, should know how to write asynchronous and parallel executing code to make our applications faster and more responsive.

This course is all about developing more responsive and fast programs. Multithreading and Parallel Computing are topics for those who already have some experience in programming, otherwise, you may face difficulties with understanding the content. Anyway, this course covers:

Theoretical foundations of asynchronous programming: main concepts, processes, threads and so on
Low-level Thread API, APM, and EAP
Task Parallel Library (TPL) including starting tasks, canceling tasks, chaining tasks, waiting for tasks, IO-based tasks, exceptions handling and other
Async and Await feature of C#
Synchronization including atomicity, Interlocked, Monitor (lock), ReaderWriterLockSlim, Semaphore, SynchronizationContext, and Mutex
Signaling constructs such as AutoResetEvent and ManualResetEventSlim, CountdownEvent and Barrier
Spinning including SpinWait, SpinLock and our own UpdateableSpin
ConcurrentCollections including ImmutableStack, ImmutableQueue, ImmutableList, Immutable Sets, ImmutableDictionary, ConcurrentStack, ConcurrentQueue, ConcurrentBag, BlockingCollection
Parallel Programming including Parallel class and PLINQ

Enroll and start learning the foundations of multithreading and parallel computing in .NET.

Master the Art of Writing Clean Code in C#

EngineerSpock — Wed, 25 Jul 2018 09:26:46 +0000

Foundations of building object-oriented infrastructures

Despite the fact that C# is a very rich on features language, it’s very common to see poorly designed and implemented types in a real world. In fact, C# is one of the richest on features language among object-oriented languages in the world nowadays. But with great power comes great responsibility. It’s challenging to use all those features in a right way.

You probably have already heard the following well-known statement: most code sucks. Well, this course is all about how to produce code which doesn’t suck.

Owning skills of producing a well-designed and well-implemented types is the prerequisite for the other developers to treat you as a real professional.

Learn how to design and implement types in C# so that the other developers won’t hate you when using one of the types developed by you. It means you are going to learn how to write code of the high quality: readable, understandable and reliable.

That’s why I decided to create a full-fledged video course “Master the Art of Writing Clean Code in C#”

Improve your knowledge of object-oriented programming in the context of clean coding and building types of high quality:

Learn how to give the best names for API members
Learn all the tricks related to writing clean functions
Avoid common architectural smells. Get rid of unpleasant smells
Apply principles of functional programming: achieve immutability, remove side effects, extend types
Avoid smells related to dependency injection
Write cleaner unit tests
Practice Test-Driven Development

Content and Overview

This course is aimed at all the C# developers, from beginners to seniors. Topics which are covered in the course are relevant for all kinds of C# developers since all developers design and implement APIs. The topics complexity is very different. There are plenty of very simple topics, and at the same time, there are topics which require from you a solid C# background. There are plenty of code examples throughout this course, so you will learn both theoretical and practical material.

The course covers the following topics:

Meta Principles: DRY, KISS, YAGNI, SoC, CQS, PoLA, Encapsulation
How to give better names to API members and what naming conventions exist in the .NET platform and suited for C#
Common problems encountered by C# developers in the process of designing and implementing APIs: classes vs structures, creational patterns vs constructors, poor naming, excessively long methods, output parameters and so on.
Common Architectural Design Smells such as Primitive Obsession, Hidden Dependencies, Violation of Law of Demeter and other.
Functional Programming: immutability, temporal coupling, pipelining, extending IDisposable, Builder Design Pattern, abusing extension methods, dealing with errors
DI-related anti-patterns: control freak, hidden dependencies, temporal coupling, ambient context, facade service, bastard injection, cyclic dependencies
Clean Unit Tests: singletons and static classes, an excessive number of interfaces, testing trivial code, testing of a single concern, different best practices
Practicing TDD: definition, 3 laws, parsing roman numerals, continuous testing, implementing Tic-Tac-Toe

The list is far from being complete. The course covers a great number of topics.

Enroll and start Mastering the Art of Writing Clean Code in C#!

EngineerSpock

SOLID Principles: Interface Segregation Principle (ISP)

Interface Segregation Principle Definition

A bit of History

Interface Segregation Principle Violation in C#

Fixing the ISP Violation

ISP Violation Example 2

Refactoring to Fix ISP Violation

Common Smells of Interface Segregation Principle Violation. Fixes and Related Patterns

ISP violation can be the root cause of LSP violation

Too fat Interface

Conclusion

SOLID Principles: Liskov Substitution Principle (LSP) In Practice

LSP Definition

LSP Violation

Contracts

Violation of Invariants

Refactoring to Remove LSP Violation

More Examples of LSP Violation

Variance

NotSupportedException Smell

Downcasts as a smell of LSP Violation

Sum Up

Conclusion

Algorithms and Data Structures in C#: Complete Tutorial

Why learn about data structures and algorithms?

Why this course?

What’s in the Course?

Introduction to Selenium

What is Selenium

Key Elements of Selenium

Writing First Automation Example

Selenium Locators

Automating Elements

Writing the First Acceptance Test with SpecFlow

Acceptance and UI Testing with SpecFlow and Selenium

Pyramid of Tests

Integration and UI Testing

Why Write Automated UI Tests?

What is an Acceptance Test?

Acceptance and UI-Automation Testing Frameworks

Complete Practical LINQ Tutorial in C#

LINQ to Entities, LINQ to Objects, LINQ to XML, Functional Programming and LINQ

Double Your Coding Speed with Visual Studio and ReSharper

Multithreading and Parallel Programming in C#

Master the Art of Writing Clean Code in C#

Foundations of building object-oriented infrastructures

Content and Overview

The course covers the following topics:

LINQ to Entities, LINQ to Objects, LINQ to XML,
Functional Programming and LINQ