If you're a programmer, focusing on the task at hand, then the answer is likely a resounding, "No, test-driven development doesn't speed up development." Any given programming task will be weighed down with the extra test code you'll be writing, and the extra thinking that TDD forces you to do.
If I closed one eye and looked at the world through a straw, I'd only a see small part of my overall work and responsibilities. I would likely have no purview of how my work fit into the larger workflow and the work done before the coding effort and after the coding effort. With such a constrained view, I wouldn't see how my work impacts others who are at work in areas of operation that feed work into the programming phase, and the areas of operation that are fed by the programming phase.
If you asked whether it would be quicker to finish a given task if I was able to write the code correctly the first time without defects or design flaws, and precisely fulfilling customer and stakeholder expectations, then it would certainly be faster for me to do that work without writing tests at all, let alone writing tests first.
If you believe "development" means all the work done in turning concepts into cash - from ideation through design, implementation, inspection, packaging, and delivery - then TDD absolutely speeds up development.
Replace the term "development" with "producing software" or "software production", and understand that we're not just talking about the work involved in writing program code for an isolated bit of functionality. Production is everything involved in turning an idea into a shipping a product, or even a new feature for an old product or a change to a feature. It's the entire pipeline of work.
The software development business has an out-dated idea of what productivity is. It's an idea the lags almost twenty years behind many other product development industries.
We try to achieve productivity by making our jobs as efficient as possible. We believe that if our job is to write code, then writing less code will make us more productive. We adopt generation after generation of high-speed programming automation tools with taglines like, "Write seventy percent less code with the new version of Visual
Good tools are a must and automation is necessary, but they rarely contribute to higher productivity when used to increase local efficiency. Focusing on local efficiency usually drives productivity down.
Test-driven development doesn't require elaborate tooling and high-speed automation. It generates its seemingly unlikely productivity by supporting the entire production pipeline's flow. It's not glamorous, but it participates in optimizing the whole while helping to avoid the trap of local efficiencies.
Whether you are personally going slower as a programmer because you're doing test-driven development isn't a relevant concern unless this slowness is also driving down the speed of the entire production system.
Test-driven development decreases complexity, improves the incremental adaptability that software product development depends on, astronomically reduces the amount of rework that destabilizes schedules, and reduces the unrecognized design flaws that decrease productivity after the initial implementation phase.
Test-driven development supports flow. The software development industry at large is years away from recognizing that flow rather than efficiency is what creates giant leaps in productivity. Nonetheless, it works, and it's supported by the production physics used by industries that are well ahead of software development in product development and production maturity and optimization.
Test-driven development may require you to have nerves of steel while you're adopting it and dealing with the antithetical notion of going slower to speed up, but it will speed things up. It just might not speed you up. At least not until you broaden your perspective and interest so that they include the entire production system.
Test-driven development touches so many aspects of the entire production pipeline that when recognized and practiced as a systemic optimization rather than a mantic, esoteric bit of programmer wizardry, it increases the productivity of the whole effort. And because of this, it's one of the best things that the programmers bring to the whole production effort.
