[collyw]

The test environment on a local machine, as the tests are pretty useless if you can't run them. There can be database issues, as you aren't going to connect to the production database for running tests locally.

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.

[dpark]

This implies your team needs to invest more in getting your local environment to parity. My team invested heavily in making the local setup identical to the pull request environment so that the testing is identical. We’ve also invested heavily to ensure that nearly[1] the exact same tests run in our continuous integration pipeline as our pull requests, with the net effect being that a break in CI is by definition an environmental difference.

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.

[softawre]

> takes no extra time

> invested heavily

pick one.

[dpark]

I did pick one and invested heavily. I never made a statement about "no extra time".

[collyw]

"So testing in browser is as expensive as writing unit tests with TDD."

[dpark]

I did not write that.

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.