Re:Write tests. Not too many. Mostly integration
by hacker_9 on Friday October 27, 2017 @09:07AM
(#15567891)
That's exactly my point, mock your external dependencies. Static calls don't allow you to do that.
Re:Write tests. Not too many. Mostly integration
by viraptor on Friday October 27, 2017 @05:11PM
(#15572263)
In your language of choice:
static_function(db, other, arguments) { ... }
test { static_function(fake_db, 1, 2) }
You can even omit the db in the standard case if your language allows default keyword arguments. In almost every language, a method is just a fancy static call that takes extra arguments implicitly. (Closures are poor man's objects, objects are poor man's closures...)
Re:Write tests. Not too many. Mostly integration
by vertex-four on Friday October 27, 2017 @09:42AM
(#15568142)
So how exactly do you test that your SQL query does the right thing? That you're using the Twitter API correctly?
Re:Write tests. Not too many. Mostly integration
by hacker_9 on Friday October 27, 2017 @10:02AM
(#15568319)
Testing a database, or an external web service, is an integration test. They can be as simple as:
void TestCreateUser() {
var repo = new UsersRepository();
var mockUser = new User("John", "Smith");
repo.AddUser(mockUser); // db call
var addedUser = repo.GetUsers().Single(); // db call
Assert.StructureIsEqual(mockUser, addedUser);
}
For the Twitter web service, you might test that you successfully get a response, as you don't have control of what exactly comes back.
It sounds like a problem is a few layers higher. Why is there a live database in your unit testing environment? Why are working credentials configured? If they're unit test, not integration tests, all db operations should be DId / mocked / whatever. Any call that isn't should fail, not take longer time. Db interaction is for the integration tests.