Dependency injection / testability – would this logic be appropriate?

In a testability perspective, would this logic be appropriate?

public class Foo {      public List<SomeClass> Elements {get; set;}      public Foo(IDataAccess _dataAccess) {        this.Elements = _dataAccess.GetElements();     }     } 

When testing the Foo class, how i know that i need to mock or fake the GetElements method of IDataAccess?

TradOffs between Testability and Performance for CQRS Pattern

My team has recently decided to adopt the CQRS pattern similar to the one used in the famous Microsoft EShopsOnContainers repository. In this solution, the queries are made in Query classes using Dapper and Commands are done in command handlers using EF Core.

The queries that I am doing on my domain are quite complex and require a lot of filtering of the data. Without using LINQ. I am relying on using purely dynamic SQL statements (not my strong point) to query my domain model with multiple WHERE clauses etc.

This approach would make it extremely hard to unit test my queries.

Here are the two approaches I am considering:

Approach 1:

string sql = @"     SELECT * FROM [dbo].[vw_LogisticsManagement]      WHERE ([Status] NOT IN @WorkOrderStatuses )     AND ([PickupDate] IS NOT NULL)      AND (0 = (DATEDIFF (day, [PickupDate], getdate()))     AND (0 != (DATEDIFF (day, [CheckInDate],  getdate())))     ORDER BY [PickupDate]";  //Add parameters etc... var result = await connection.QueryAsync<viewModel>(sql, parameters); 


  • Very Performant


  • Difficult to test
  • Difficult to write (for someone without much SQL experience)

Approach 2

string sql = @" SELECT * FROM [dbo].[vw_LogisticsManagement]  var result = await connection.QueryAsync<viewModel>(sql, parameters);  var wos = result.Where(wo => wo.PickupDate.HasValue                 && wo.PickupDate.Value.Date == DateTime.Now.Date                 && wo.CheckInDate.Value.Date != DateTime.Now.Date                 && wo.Status != Status.Shipped                  && wo.Status != Status.PartiallyShipped)                 .OrderBy(wo => wo.PickupDate).ToList(); 


  • Very easy to write (someone with a lot of LINQ experience)
  • Easy to test filters: I could mock the result that Dapper returns (no need for in memory db) and then have a predefined list that I could apply the filters using LINQ and have an expected result


  • Not as performance. Enough to even matter?

So basically I am trying to weigh out the pros and cons of each, in my opinion testability outweighs the potential performance boost in this case, however not everyone from my team would be likely to agree.

Ultimately approach 1, with proper testing in place would be ideal as many of the queries I am dealing with are far more complicated.

Balancing function call overhead and testability in a code that is a part of the deep learning model training loop

I am currently implementing the transformer architecture for sequence to sequence problems. Key part of the model is the attention mechanism, which is basically a matrix multiplication, followed by a masking operation and a softmax function. My initial thought was to wrap this 3 steps in a function, that looks like this:

    def attention(self, matrix_1, matrix_2, mask=None, trans_1=False, trans_2=False):         att_stage_1 = F.matmul(matrix_1, matrix_2, transa=trans_1, transb=trans_2)*self.scale_score         att_stage_2 = F.where(mask, att_stage_1,, 'f')*(-1e9))         return F.softmax(att_stage_2, axis=3) 

I want to write unit tests for this function to test whether the output is what I expect it to be. The problem, however, is that this function, as it is, performs 3 separate operations: matmul, masking and softmax. I would prefer to determine that each of this operations does produces correct output, but as it is I could only check the final effect. This leads me to a design where I would wrap each of this 3 operations to a separate, dedicated function and test them separately. What I am concerned, however, is that the overhead of python functions calls in a training loop function that is called on each forward pass may be unnecessary.

Thus, the question is, what would be the correct approach to balance design and reliability vs performance in this scenario? Maybe I am missing some obvious approach here.

How to structure a set of classes that deal with external APIs for maximum testability?

I’m developing a set of classes designed to communicate with external APIs, and I’m running into trouble with how to properly structure everything for proper loose coupling and unit testing.

Currently, each API we need to talk to has a distinct class, which implements an interface a bit like this:

public interface IApiIntegration {     Task<string> SearchApi (List<string> searchValues);     Task<string> GetFromApi(string idToGet);     Task<bool> PostToApi(PostObject api); } 

Each api class inherits from a base abstract with implements this interface. That class also contains a number of helper functions which are only relevant to handling data coming to and from Apis.

Beneath the public PostToApi method of each class there are also a bunch of helper functions to build the object to be posted. These are often quite complicated, and could really do with testing. However, they’re specific to the class in question and are thus private.

Inside every public function on IApiIntegration there is also, of course, a call to an external Api. For example it might look something like:

public override async Task<string> GetFromApi(string id) {     string result = "";     string path = $  "{integration.RootUrl}items/{id}?username={integration.Username}&key={integration.Password}";      // client is a static instance of HttpClient     HttpResponseMessage response = await client.GetAsync(path);     if (response.IsSuccessStatusCode)     {         result = await response.Content.ReadAsStringAsync();     }      return result; } 

This leaves me with two problems:

1) It feels right that the helper methods in the base class and the individual classes should be open to unit testing, but also that they should be protected/private. Something, therefore, is clearly wrong with the structure.

2) It’s obviously wrong to be testing external APIs so I need somehow to bypass or mock out those dependencies. But that’s not possible in this structure.

How can I refactor and restructure this to ensure everything is open for unit tests?