Not sure about other types of development, but in web development, TDD can be a good way to have automated tests without the additional cost.
Sorry for any confusion for anyone reading my previous comments.
And indeed, tests don't take much time to write once you get used to writing them. It's like anything. The more you do it, the better you get at it.
We have a full continuous integration environment at work, and the tests run there fine, but trying to reproduce that on a local machine is often a fairly difficult experience.
We have maybe 30 components in our system, so often I haven't touched the component before and I am asked to fix a bug in it. Sometimes they are using standard testing libraries, other times there are a lot of extra libraries that I haven't used before. Getting everything to play nicely isn't always trivial.
This drastically scopes down the surface area for CI breaks.
[1] There are a few exceptions for tests that specifically cover environmental config/behavior that cannot be fully tested locally.
> invested heavily
pick one.
But also, testing in browser is more expensive long term that writing proper automated tests. Up front it’s cheaper, like any other technical debt.
If you’re very familiar with testing and/or doing TDD, you might include your testing costs in your estimate, but you still have the cost to pay. And if you write good testing up front, it will cost more up front.
Cake + Eat-it, too.
In the browser, testing edge cases sometimes requires custom headers, encoding of data to create authorization tokens, etc. This means you have to either have amazing browser tools (which I've yet to find) or use a combination of browser and shell to achieve what I need.
In TDD, most setup can be automated with simple function calls. In addition, well made frameworks, such as PHP's Symfony, have utilities that even avoid making real HTTP requests, so tests run faster than using a browser, but the result is the same.
I'm not saying everyone should do TDD, but from my experience, it can lead to increased productivity and fewer bugs in some cases.
By the way, if you know of browser tools that make testing easier, I'd be glad to learn more. I use TDD because I lack the browser tools. If I had the right tools, maybe I'd consider going back to in browser testing.
When my function under test calls sort() I don't fake that call out, so technically I just wrote an integration test. (In fact I work with one group that will inject a fake sort())
If I write a library foo which has sub-module bar which has class baz and fuzz, is the test for bar that tests both baz and fuzz a unit test of an integration test? Of course if you are a user of my library tests for foo are unit tests to you...
There's no agreement what is "unit". Few classes interacting with each other could still be a unit.
I didn't find any strict definition which would be useful in practice. I just write tests and guess they are mostly integration tests, some end-to-end tests and a few unit tests.