Peter Morlion logo

Using git bisect to find the origins of code

Every now and then, I encounter some complex legacy code that has been moved around and changed so much, git blame doesn’t help in finding the original commit. Git bisect is the solution here. Why the Original Commit Can Help Sometimes, I read code and (after a while) it becomes clear what it does. But […]

Code coverage without unit tests

While working on a legacy application for a client, I wanted to get some code coverage for my tests. In Python, this usually means running Coverage.py and pointing it to your unit tests. This being a legacy application, there were no unit tests. There were Postman tests however. This is a simple technique that is […]

Escaping the Catch-22 of Anti-Test Arguments

There’s a Catch-22 hidden in the arguments that many people use to rationalize not writing tests. The Catch A Catch-22 is a situation that you can’t escape out of due to contradictory rules or limitations. In case of automated tests for software, the arguments often go like this. At the start of the project, both […]

How to Get Away with Unit Testing Legacy Code

A while ago, I did a webinar for TypeMock about unit testing legacy code. It’s about why we want to unit test legacy code, the advantages and disadvantages, and it includes some minor live coding using TypeMock’s Isolator tool. You can watch it here: I hope you like it. Let me know what you think!

Fixing My Legacy Application: NDepend Rules

Here I am again with a follow up post in my series on fixing a real world legacy application. I’ve been continuing my work with NDepend and wanted to give an update on what it has helped me do. Just a small reminder: the application is a web application to make forecasts about the World […]

Fixing My Legacy Application: NDepend

In my series of fixing a real-world legacy application, I’ve already improved the code in some big blocks: updated Bootstrap introduced dependency injection removed unnecessary cruft added logging But fixing legacy applications often means making many smaller improvements. Many of these are often a matter of personal opinion. And when multiple developers do agree on […]

A Blog For Your Manager

I’ve written multiple posts about legacy code and automated tests. I believed both are closely connected in that one can help solve the other. I also enjoy working on legacy code, improving software development practices and improving code quality. But this blog has always been geared towards developers, and it seems managers don’t always follow. […]

Fixing My Legacy Application: Adding Logging

This application contains absolutely no logging. In many legacy enterprise application, there usually is some logging, but it’s often not very useful. In some cases, there is no logging at all. This makes it hard to troubleshoot when things go wrong. In .NET, the first logging frameworks that come to many developer’s minds is log4net […]

Fixing My Legacy Application: Dependency Injection

Continuing my series on fixing my real-world legacy application, I will now introduce dependency injection. First, I simply installed the Autofac.Mvc5,¬†Autofac.Mvc5.Owin¬†and Autofac.WebApi2.Owin NuGet packages. This changes nothing of course. So next, we tell ASP.NET to let Autofac handle the creation of the controllers. In our Startup class, we add: This is basically what’s in the […]

Fixing My Legacy Application: Removing Unused Components

When I first started writing this app, I wanted to move fast. I found a JavaScript library that promised to connect my client-side code to my Entity Framework context very easily: Breeze. For some reason that I can’t remember now, I never ended up using very much of it, if anything at all. But I […]