It seems to me when you do,,,,
ADODB.Recordset temp = new ADODB.Recordset(); temp.Open();
it looks for a connection and you get an error because the connection is closed/not exist.
Of course with Unit tests you want to avoid talking to any configuration or external systems. If you do want, then it would be an integration test.
What you can do is to couple of fake implementations that mimic the behaviour of the record set. This is only during the test execution. During the actual app execution you would use a real record set.
The way you wire this up would be something like below. You need to introduce couple of interfaces as below.
Create an Wrapper Interface around your VB ADODB Record Set object. It would have bunch of methods which allows you to manipulate the real record set. Something like below.
public interface IRecordSet {
void Open();
void AddNew();
void Add(string key, object value);
}
Create a factor the allows you to have access to an implementation of an IRecordSet. Something like below
public interface IRecordSetFactory {
IRecordSet Create();
}
public class RecordSetFactory : IRecordSetFactory {
public IRecordSet Create()
{
return new ADODB.Recordset();
}
}
Your SUT (System Under Test would use the RecordSetFactory and allows you create a new ADODB.Recordset()
Now during your Unit Testing you can change the real behaviour as desired.
In your test area create a Stub/Fake Record Set instead of the real one (Since you haven't stated that you are using any isolation/mock object framework, you can simply roll out a hand written stub as below.)
public class StubRecordSetFactory : IRecordSetFactory
{
public IRecordSet Create() {
return new StubRecordSet();
}
}
Your Test can now use the StubRecordSet
[TestMethod]
public void YourWhatEverTest()
{
var factory = new StubRecordSetFactory ();
var stubRecordSet = factory.Create();
//call SUT
//...
//Any asserts/verifications
//...
}