Does Unit Test mean that the test has to be mocked or definition of Unit Test can be without mocked?
For example below, this test is mocked, so it is unit test:
/**
* @test
*/
public function it_should_return_true_if_ssh_client_is_connected()
{
$this->phpSecLibShh->shouldReceive('isConnected')->andReturn(true)->once();
$this->assertTrue($this->shell->connected($this->phpSecLibShh));
}
Example below, is this Unit Test or Integration Test? I am not clear about this:
/**
* @test
*/
public function it_should_get_half_price_discount()
{
$cost = 50;
$order = new Order();
// It does not connect to database or any other service
$discounted = $order->discount(Order::DISCOUNT_HALF_PRICE, $cost);
$this->assertEquals(25, $discounted);
}
The main idea of mocking is to decouple the dependency. Unit tests shouldn't have any kind of dependency. Say your business logic connecting to database layer which in turn connects to database. Now you are writing a unit test to test your business logic. If you are not decoupling database base layer from business logic then your unit test will go and hit database, which should never happen. So what you should do is to inject the database dependency to business logic layer and when writing unit test mock that dependency.
Long story short you don't need mock always for unit tests but if any dependency then that should be mocked. If your test has any dependency (say database dependency, file dependency etc.) then your test is not unit test but integration test
Vijay, from my experience, the team will be the best judge to decide if they needs a solitary/social/adaptive unit testing strategy, since there is no "One size fits all solution".
Having said that, I believe being adaptive is probably more practical. Almost all of the mid to large sized monolithic applications will have atleast one external dependency which may not be available in the development/test environments( eg: payment gateway/ Decision engine ) . Mock data will be our only option here. However with in the same unit test case we could club another sociable scenario too( by calling another function with in the same class/namespace). It may even be possible for the second function to have its on separate mocked test case. Thus it could become an adaptive unit testing strategy where the team takes a collective stand in terms of what they call an unit and what the strategy to be used on a scenario by scenario basis. We also should bare in mind that when we start building a deployment pipeline our unit test cases could be executed as part of an automated process which by itself be provisioning the enviroments. Hence it may be benificial to keep our unit testcases isolated from any database/file dependencies.
In future when more and more applications move into Microservice architecture and containerisation we'll have more clarity around the unit testing strategy to be used. Development /Deployment will be done in stateless and independently deployable/manageable chunks. Tools like Docker Daemon APIs can be used to spin up a container which hosts a specific related/dependent service/functionality and run it as part of our test case execution , this will prevent us from having to mock other services , since we could easily activate a light weight container with the relevant service and test it.