Introduced IPostmarkClient interface for better testing experience.

[smoelker]

It very hard to mock the PostmarkClient at the moment because it does not implement an interface nor are it's members virtual.

This is not allowed for example

var postmarkClient = new Mock<PostmarkClient>();
postmarkClient.Setup(x => x.SendMessageAsync(It.IsAny<PostmarkMessage>()))

Error message
System.NotSupportedException : Unsupported expression: x => x.SendMessageAsync(It.IsAny<PostmarkMessage>()) Non-overridable members (here: PostmarkClient.SendMessageAsync) may not be used in setup / verification expressions.

This PR introduces an interface for all public members.

[vladsandu]

@smoelker thank you for submitting this PR and sorry for the delay in replying here.

Adding an IPostmarkClient interface for better testability was previously discussed in detail in another issue (#20), with reasoning behind why this was removed in the first place and different solutions for mocking this in tests.

Considering the recent feedback received in the above-mentioned issue, I do agree that for a user of this library, the most common concern when mocking the PostmarkClient in unit tests is to ensure dependencies are properly satisfied/parameters are properly passed in as part of the larger business logic and process. Since the library's goal is to facilitate communication with an external service, ensuring client internal behaviour is likely not worth the extra setup for most users, as they would probably like to treat the client as a "black-box" that just works according to the specifications.

Since this is an open-source project aimed at a larger audience, I incline towards adding this interface back in the project to make the developer experience simpler and easier to extend.

@atheken what is your current opinion on this?

[JosKrause]

Sorry to barge in, but on a scale of 1 to 10 how dead is this project? I'm looking for a proper SendGrid alternative but the code and support for newer frameworks is nowhere to be seen? Are you part of the official team or just helping them with this library?

No .NET Core 3.1 or 5.0 support, no updates on code and C# usage/improvements. Don't get me wrong, I can completely understand the burden of upkeep and motivation, but I am trying to assess whether this library is dead on arrival, or worth forking and just adding the missing tidbits myself?

Appreciated :)

[JosKrause]

@smoelker though I understand your wish to mock the client, I would opt to just creating your own abstraction around it. I did the same thing for SendGrid. I have no interest to mock their implementation, so I simply created an IMailService interface with the methods that make sense for my (business/functional) logic and have a SendGridMailService implement that, giving me the ability to swap that out for PostmarkMailService when it becomes an option.

Then your testing is around your IMailService requirements and you are also not dependent on changes on the original API as your (functional) requirements are covered by code you fully own and control.

[vladsandu]

@JosKrause I am part of the Postmark team and this project is one of the official libraries that we are maintaining.

We are ensuring that the library has feature parity with the Postmark API and that it is compatible with major frameworks, including the latest ones that you mentioned (as we are targeting netstandard2.0). Also, we will actively tackle any major issues that affect the users of this library.

We are also open to discussing and reviewing pull requests for improvements from the community.

That being said, at the moment we do not have the capacity to make bigger refactorings/improvements to usability or explore newer language features. But we are taking these topics and other existing issues into account for dedicated future work.

[dansiegel]

So a few things I would like to address from this thread. Much like @JosKrause I am looking for an alternative to SendGrid.

Sorry to barge in, but on a scale of 1 to 10 how dead is this project?
No .NET Core 3.1 or 5.0 support

That is absolutely absurd statement. Any .netstandard2.0 library naturally supports netcore3.x, net5+.. there is no reason for an explicit build target.

Regarding this actual PR though, I do find it quite sad that this PR has been open for more than a year. Nobody typically questions whether or not the PostmarkClient is tested. I think most people expect that it is, and that they understand there is no need to test it themselves. The entire point of an interface is to better support the consuming developer being able to test their own code. Let's take the example straight from the wiki:

var sendResult = await client.SendMessageAsync("<sender signature>", 
			"ben@example.com", 
			"Hello from Postmark!",
			"This is just a friendly hello from your friends at Postmark.");
if (sendResult.Status == PostmarkStatus.Success){ /* Handle success */ }
else { /* Resolve issue.*/ }

The reason why the interface and mockability are important is to test how we as the library consumer handle the Success or Error states that the library could return. I would really like to see this issue take a bit higher priority.

@vladsandu I realize you may have a small team and do not have the capacity to make bigger refactorings/improvements but this surely should not fit in that category.

[PlaidPhantom]

To help the next person who comes along searching for this, here's some quick adapter code I just used to solve the problem:

public interface IPostmarkAdapter
{
    Task<PostmarkResponse> SendMessageAsync(PostmarkMessage message);
    Task<PostmarkResponse> SendMessageAsync(TemplatedPostmarkMessage message);
}

internal class PostmarkAdapter : PostmarkClient, IPostmarkAdapter
{
    public PostmarkAdapter(string token) : base(token) { }
}