I am debating re-writing a plugin for AutoCAD, which uses the .NET C# API. The current version of that plugin does not have unit or integration tests. This is because unit tests cant really be written if you are using the AutoCAD API's objects as they only exist in an AutoCAD runtime. Which would lead to integration tests, which as do able just require a bit of extra work.
In order to implement unit testing, the domain/business logic would need to be extracted. I started working on this, but quickly start asking "Is this going to be worth it?"
For example one of the most important/foundational types in my plugin is a "Zone"
public class Zone
{
private readonly IZoneDataProvider? _dataProvider;
private readonly IZoneGeometry? _geometry;
public Zone(IZoneDataProvider dataProvider, IZoneGeometry? geometry = null)
{
_dataProvider = dataProvider;
_geometry = geometry;
}
public string? ZoneId
{
get => _dataProvider?.ZoneId;
set => _dataProvider?.ZoneId = value;
}
public bool IsInside(Point3? point)
{
if (point is null || _geometry is null) return false;
return _geometry.Contains(point.Value);
}
}
This is a simplified version of a the Domain class for a Zone. A Zone in AutoCAD is a Polyline, which is an AutoCAD type.
IZoneDataStore is for handling the storage of business logic related data. ZoneId is assigned to the Zone. For unit testing an in memory data store would be used. In an AutoCAD environment a wrapper class around an AutoCAD Polyline object would be supplied and handle the storing of data on that AutoCAD object.
IZoneGeometry is for other AutoCAD objects to query their location against a Zone to see if they are inside, leading to other business rules.
That explains IZoneDataProvider and IZoneGeometry, which are both implemented in classes for unit testing as well as in adapter classes for AutoCAD.
Where I start asking the question "Is all this extra work worth it?" is when I get to another business rule. One example is a change the color of the Zone Polyline and other objects to match that color.
When a Polyline is "made" a Zone its color is changed according to its ZoneId and some business logic which isn't important. But if I want to add this to the domain object as business logic, I then need an interface like
public interface IZoneColorEntity
{
public short? CurrentColor { get; set; }
}
So now the adapter class for the Polyline which represents an AutoCAD Zone not only needs to implement IZoneDataProvider, IZoneGeometry, and now IZoneColorEntity.
In essense it feels like I'm making interfaces that mirror the AutoCAD API, because the business logic really is tied to manipulating those objects in CAD.
And this is only the first main class I'm implementing that I'm running into this thought. I wonder if it might be better to just ignore the unit test idea all together and just focus on integration tests? Essentially removing the idea of a Domain project.