(C#) 使用 DI 和自定义通用 Class 进行单元测试

Question

I am working on doing a Unit Test. My problem is i cant seem to find a way to make a test for the Logic class. Because the Logic class is dependend with the SQL class. i haved tryed some Test but so far no good results.

Here is the Logic Class. Im using a Custom Generic Class for the Database Connection Class. AccountFE = is a modified DTO.

 public class AccountsLogic
    {
      SQLGeneralDB<AccountFE> Database = new SQLGeneralDB<AccountFE>();

            public List<AccountFE> ReadFromDB()
            {

                string sqlcommand = " SQl query command";

                try
                {            
                    List<AccountFE> accounts = Database.ReadTable(sqlcommand);                            

                    return accounts;
                }
                catch (Exception ex)
                {
                    throw;
                }    
            }
    }

Here is the SQL Class. This is not that important. This is only to show why i used Generic for this class. (Serialization and Deserialization)

public class SQLGeneralDB<T> where T : class, ISQLGeneralDB, new() 
    { 
       public List<T> ReadTable(string sqlcommand)
           {            
               var selectedlist = new List<T>();
               using (SqlConnection cnn = new 
            SqlConnection(XmlWebConfigReader.GetValueFromWebConfig("connectionstring")))
            {
                cnn.Open();
                using (SqlCommand command = new SqlCommand(sqlcommand, cnn))
                {
                    SqlDataReader dataReader;
                    try
                    {
                        dataReader = command.ExecuteReader();

                        while (dataReader.Read())
                        {
                            object[] objectarray = new object[dataReader.FieldCount];
                            dataReader.GetValues(objectarray);
                            ISQLGeneralDB objectfetcher = new T();

                            selectedlist.Add((T)objectfetcher.FetchRow(objectarray));
                        }
                        return selectedlist;
                    }

                    catch (IndexOutOfRangeException)
                    {
                        throw;
                    }
                    catch (Exception ex)
                    {
                        throw;
                    }
                    dataReader.Close();
                }
                cnn.Close();
            }

        }    
}

interface ISQLGeneralDB for multiple DTOs.

public interface ISQLGeneralDB { object FetchRow(object[] objectarray); }

i hope that its not to confusing and that i explained it good.

Answer 1

Some general considerations:

1. Abstract your dependencies to interfaces.
2. Inject you dependencies eg via constructor: public AccountsLogic(ISQLGeneralDB db){}
3. In the test, mock your dependencies, eg with moq

Now let's apply it to your code. If you want to abstract your dependency, you need to abstract the SQLGeneralDB as well, eg:

public interface IMyDbInterface<T> where T : class, ISQLGeneralDB, new() {
    List<T> ReadTable(string sqlcommand);
}

public class SQLGeneralDB<T> : IMyDbInterface<T> where T : class, ISQLGeneralDB, new() {

    //...

}

and than mock the IMyDbInterface<AccountFE> :

var myDbMock = new Mock<IMyDbInterface<AccountsLogic>();
myDbMock.Setup(c => c.ReadTable(It.Is<string>(d => d....your condition....).Returns(....whatever you want to return....);

Although that would be rather complicated. I'd personally would go here with the repository pattern , so something along the lines:

public interface IRepository<T> where T: class, IEntity
{
  IEnumerable<T> GetAll();
}

public interface IEntity
{
  // E.g.:
  long Id {get;}
}

public class Account : IEntity { ... }

public class AccountRepository : IRepository<Account>
{
  public IEnumerable<Account> GetAll()
  {
    // ... your stuff with SQL commands
  }
}

And than you mock it all. Your repository knows how to get accounts, including that SQL command, not the calling code.

The fact that your class is generic doesn't make it special in relation to mocking. You just mock a generic implementation.

Answer 2

Many are getting confused by the interface in the question. The generic class is not derived from that interface, the generic argument of the class is what is derived from the interface.

Current code is tightly coupled to implementation concerns that make it difficult to test it in isolation (unit test)

Classes should depend on abstractions and not concretions. In this case the generic class should have a generic abstractions.

The generic interface would look something like the following.

public interface ISqlDatabase<T> where T : class, ISQLGeneralDB, new() {
    List<T> ReadTable(string sqlcommand);
}

The current naming choices may cause some confusion. The implementation would then be derived from this abstraction

public class DefaultSqlDatabase<T> : ISqlDatabase<T> where T : class, ISQLGeneralDB, new() {
    private IDbConnectionFactory factory;

    public DefaultSqlDatabase(IDbConnectionFactory factory) {
        this.factory = factory;
    }

    public List<T> ReadTable(string sqlcommand) {
        var selectedlist = new List<T>();
        using (IDbConnection connection = factory.CreateConnection()) {
            connection.Open();
            using (IDbCommand command = connection.CreateCommand()) {
                try {
                    command.CommandText = sqlcommand;
                    using (var dataReader = command.ExecuteReader()) {
                        while (dataReader.Read()) {
                            object[] objectarray = new object[dataReader.FieldCount];
                            dataReader.GetValues(objectarray);
                            ISQLGeneralDB objectfetcher = new T();
                            selectedlist.Add((T)objectfetcher.FetchRow(objectarray));
                        }
                        return selectedlist;
                    }
                } catch (IndexOutOfRangeException) {
                    throw;
                } catch (Exception ex) {
                    throw;
                }
            }
        }
    }
}

Note the supporting types

public interface IDbConnectionFactory {
    IDbConnection CreateConnection();
}

public class SqlConnectionFactory : IDbConnectionFactory {
    public IDbConnection CreateConnection() {
        return new SqlConnection(XmlWebConfigReader.GetValueFromWebConfig("connectionstring"));
    }
}

The subject class would be refactored to be dependent on the abstraction

public class AccountsLogic {
    private readonly ISqlDatabase<AccountFE> database;

    public AccountsLogic(ISqlDatabase<AccountFE> database) {
        this.database = database;
    }

    public List<AccountFE> ReadFromDB() {
        string sqlcommand = " SQl query command";
        try {}
            List<AccountFE> accounts = database.ReadTable(sqlcommand);
            return accounts;
        } catch (Exception ex) {
            throw;
        }
    }
}

which can be mock as needed when testing AccountsLogic in isolation, since it is no longer dependent on implementation concerns.

At run time all implementations can be mapped to their abstractions and added to the composition root for injection into their dependent classes.