开发者

Unit Testing.... a data provider?

开发者 https://www.devze.com 2023-02-01 07:04 出处:网络
Given problem: I like unit tests. I develop connectivity software to external systems that pretty much and often use a C++ library

Given problem:

  • I like unit tests.
  • I develop connectivity software to external systems that pretty much and often use a C++ library
  • The return of this systems is nonndeterministic. Data is received while running, but making sure it is all correctly interpreted is hard.

How can I test this properly?

I can run a unit test that does a connect. Sadly, it will then process a life data stream. I can say I run the test for 30 or 60 seconds before disconnecting, but getting code ccoverage is impossible - I simply dont even comeclose to get all code paths EVERY ONCE PER DAY (error code paths are rarely run). I also ca开发者_StackOverflown not really assert every result. Depending on the time of the day we talk of 20.000 data callbacks per second - all of which are not relly determined good enough to validate each of them for consistency. Mocking? Well, that would leave me testing an empty shell of myself because the code handling the events basically is the to be tested case, and in many cases we talk here of a COMPLEX c level structure - hard to have mocking frameworks that integrate from Csharp to C++

Anyone any idea? I am short on giving up using unit tests for this part of the application.


Unit testing is good, but it shouldn't be your only weapon against bugs. Look into the difference between unit tests and integration tests: it sounds to me like the latter is your best choice.

Also, automated tests (unit tests and integration tests) are only useful if your system's behavior isn't going to change. If you're breaking backward compatibility with every release, the automated tests of that functionality won't help you.

You may also want to see a previous discussion on how much unit testing is too much.


Does your external data source implement an interface -- or can you using a combination of an interface and a wrapper around the data source that implements the interface decouple your class under test from the data source. If either of these are true, then you can mock out the data source in your unit tests and provide the data from the mock instance.

public interface IDataSource
{
     public List<DataObject> All();
     ...
}

public class DataWrapper : IDataSource
{
     public DataWrapper( RealDataSource source )
     {
         this.Source = source;
     }

     public RealDataSource Source { get; set; }

     public List<DataObject> All()
     {
          return this.Source.All();
     }
}

Now in your class under test depend on the interface and inject an instance, then in your unit tests, provide a mock instance that implements the interface.

public void DataSourceAllTest()
{
    var dataSource = MockRepository.GenerateMock<IDataSource>();
    dataSource.Expect( s => s.All() ).Return( ... mock data ... );

    var target = new ClassUnderTest( dataSource );

    var actual = target.Foo();

    // assert something about actual

    dataSource.VerifyAllExpectations();
}
0

精彩评论

暂无评论...
验证码 换一张
取 消