When TDD doesn't click, something else should click "harder"!

That's why I believe you shouldn't unit test your UI.

By definition, you can't unit test your UI, because it's not a single unit of code. A unit test is a test for a single unit of code, be it a function, a class or other logical unit, and the UI can't be described as a single unit of code. You can, and should, write higher-level tests for it, to make sure it fits together as expected, but you can't write a unit test for your UI.

However, you can and should write unit tests for individual components of your UI. In the example I gave of a React-based datepicker, you should write tests to ensure that it renders consistently based on given input, and it reacts in the correct way to various events. Or in the case of a jQuery plugin, you should test that it makes the appropriate changes to the DOM.

I understand what you mean, but really, do the user care about covering all the small details in the background? or do they want an overall working product?

Typically, the end-users aren't the ones you're held accountable by, the stakeholders are. And they're the ones who'll be affected if it turns out there's a fencepost error in a class that means clients have been undercharged. Unit tests tend to catch a different class of error than higher-level tests, because they're for testing that a class or function behaves as expected.

Plus, if there's a component you build and plan to reuse on other projects, such as a shopping cart, by definition you can't really test it alone by any means other than unit tests.

Don't get me wrong, unit tests alone won't catch every issue, but neither will high-level acceptance tests. There's a reason why Google advocate the so-called Testing Pyramid model, with unit tests making up 70% of the tests, functional tests another 20%, and high level acceptance tests the remaining 10%.

In addition, the other main benefits of unit tests are that they drive a better, more decoupled design, and tend to encourage the mental "flow" state that is most productive for developers.

It means you're testing what the mock is supposed to do, and NOT what the what the service as a whole is supposed to do... you're basically cheating yourself with a passing test for that mock code that's guaranteed to work.

No, that is categorically NOT the case. At no point in the example I gave does it make any assertions whatsoever about the response received from the mock. And it's quite patently wrong to state that it's "guaranteed to work". It's guaranteed to receive the specified input - you're simply testing how the class under test reacts to that input. To write good unit tests, you should treat the class under test as a "black box" - your test should pass in the input and verify it receives the correct output in response.

The whole reason to mock out dependencies in this context is so that we have absolute control over all the input to our class. We're setting up our expectations on our mock so we can make sure that:

• it makes the calls we are expecting it to make to the mocked dependency, with the expected arguments, and
• given it receives the response we specify on our mock, we can demonstrate that it reacts in the appropriate way

For instance, say we have the following code for an API wrapper:

$response = $this->client->get($url);
if ($response->getStatusCode() == 402) {
    throw new PaymentRequired;
}
if ($response->getStatusCode() == 401) {
    throw new RequestNotAuthorized;
}
return $response->getContent();

In this case, there are three possible paths through the method, depending on the HTTP status code returned. I'd test these as follows:

• For the first case, I'd have the mock of the client return a response object with a status code of 402, and assert that my wrapper class throws the PaymentRequired exception.
• For the second case, I'd have the mocked client return a response object with a status code of 401, and assert that the wrapper class throws the RequestNotAuthorized exception.
• For the third case, my mock would return a response object whose content reflected a typical response from the API in question, and I would assert that the response received from the wrapper class was as expected. It's perfectly fine, and in fact commonplace, for the wrapper class to transform this response in some fashion, so the response received from the wrapper class may not simply be the exact same response received from the API, and the test should reflect that.

There are no assertions whatsoever made about the response received from the mocked HTTP client - indeed, no assertions should be made about the response from the mock, because we already know those as we set them earlier in the test. Every single assertion is about how the wrapper class handles the response from the mock. As mentioned, it's about having complete control of the input to the class being tested, so that you can be absolutely certain that under a specific set of circumstances, the class will behave in the predicted fashion.

you end up testing the framework

This is absolutely not true, because that part of the framework is mocked. At no time does the class under test interact with the mocked class, only with the mock. And where possible I would mock the interface that the class implements, not the actual concrete class.

I generally work with Laravel (which should feel somewhat familiar as it takes some inspiration from .NET), and in that it's commonplace to create an interface for a dependency and resolve that interface into a concrete class using dependency injection. So, for instance, if I had an application that needed to fetch weather reports for a particular geographical location, I might write the following interface:

<?php

namespace App\Contracts\Services;

use App\Objects\WeatherReport;

interface Weather
{
    public function get(string $name): WeatherReport;
}

Then I might create a class at App\Services\Weather\YahooWeather to implement that interface, and have the container resolve the interface to that class. If I need to migrate to OpenWeather, I simply create a new class implementing that same interface, and change the resolution, but no classes that use that service should need to change. My unit tests for the class that uses that service would mock the interface for the service, rather than any one implementation of that interface, to ensure it would work consistently with all of them.

It has to be said, HTTP clients are a particularly tricky example in this regard. In the PHP world, PSR18 has been recently accepted as a standard interface for HTTP clients, but it's a long way from widespread adoption. Once it is more widely adopted by client libraries, it'll be easy to have API clients specify only that interface and have it resolve to a concrete class through DI, but until that time HTTPlug is the best option in PHP. Technically it's a bad practice to mock a concrete class rather than an interface, but sometimes it's just not practical to do otherwise, and in a context where you can rely on that class being there and remaining consistent, such as when it's part of the framework, sometimes it's just not worth the hassle of wrapping that class, and it makes more sense to just mock that concrete class than to go down the rabbit hole of creating an abstraction on top of it that implements a specific interface and mocking that interface.

Of course you can create mocks for each and every service you face, but aside from the fact "it's not my business"... I don't have the luxury of time to do that, and I'm sure you don't as well.

If you're manually creating a lot of mocks, then yes, that is a chore, but that's no reason not to test, but a reason to look at how you're testing. And if the alternative is testing manually, I sure as hell don't have time to do that when I could just run the test suite in a matter of seconds. Plus, it's really, really scary how often there will be small changes made that are only caught by good unit tests, and if not caught could cause problems.

I think you might benefit from taking a look at some of the spec-style testing frameworks. Personally, I find that xUnit-style testing frameworks such as PHPUnit and NUnit don't enable the best workflow for TDD, partly because they require you to manually create your mock objects. I believe NSpec is the most prominent one of these in the .NET world.

A year or two ago I started using PHPSpec for an API client, and I've found that to be the best TDD experience I've ever had. A typical test method in PHPSpec looks like this:

function it_can_get_departures(HttpClient $client, MessageFactory $messageFactory, RequestInterface $request, ResponseInterface $response)                                                
{                                                                                                                                                                                         
    $appId = "Foo";                                                                                                                                                                       
    $key = "Bar";                                                                                                                                                                         
    $this->beConstructedWith($appId, $key, $client, $messageFactory);                                                                                                                     
    $url = "http://transportapi.com/v3/uk/train/station/NRW/live.json?app_id=$appId&app_key=$key&destination=LST&train_status=passenger";                                                 
    $messageFactory->createRequest('GET', $url)->willReturn($request);                                                                                                                    
    $client->sendRequest($request)->willReturn($response);                                                                                                                                
    $this->getDepartures('NRW', 'LST')->shouldReturn($response);                                                                                                                      }                          

This is about as complex as test methods ever get in PHPSpec (and most of that is because setting up requests with HTTPlug can be rather verbose), and most are far simpler. The beConstructedWith() method is only ever required when you want to override the default dependencies passed to the constructor - most of the time, your test will define a single let() method that specifies the default dependencies used to construct the class, as in this example:

function let (HttpClient $client, MessageFactory $messageFactory)                                                                                                                         
{                                                                                                                                                                                         
    $appId = "Foo";                                                                                                                                                                       
    $key = "Bar";                                                                                                                                                                         
    $this->beConstructedWith($appId, $key, $client, $messageFactory);                                                                                                                     
}

The typehinted dependencies are mocked out automatically, so you need only typehint a specific class to get a mock of it, and you can then set any expectations you need on it. This results in more concise tests, and you have to write less boilerplate than for an xUnit-style test.

So, to keep your tests more "honest", and not cheating yourself, the person who wrote that service (say HTTPClient) is supposed to write its mock as well so that you don't WRITE your own mock, but you USE an already built mock.

It's not a matter of writing a mock. I don't know enough about .NET to comment on how easy it is to mock dependencies, but I use Mockery in PHP if I write a PHPUnit test, and it's really trivial to mock a class with that, and for most purposes it wouldn't be useful to provide a mock version of that class, since you'd still need to set the expectations for it. If I mock a class with Mockery, I'm typically looking at one line of code to mock the class, and another line per expectation, which isn't exactly onerous. I have never needed to create any kind of mock server for this kind of use case.

HTTPlug is one of the few libraries I can think of that does have this sort of behaviour, as it has a mock driver that collects requests and returns specified responses, but it wouldn't require much more code to replace that driver with a mock of the driver interface.

actually it is... ¯\(ツ)/¯

Oh, that changes everything. I understood TDD as starting with a test case that fails its assertions only and getting the function set up properly beforehand (mocks, injected dependencies, etc.) was the difficult part. If it's just getting the task requirements in as test cases at the start, that's what every single TDD explanation is missing.