Hacker News Reader

Comment by conradk | Hacker News Reader

What I mean is that compared to testing in browser, writing unit tests and using those tests instead of the browser takes about the same amount of time. So doing tests in browser or in TDD ends up taking the same amount of time upfront. So testing in browser is as expensive as writing unit tests with TDD.

View on HN

The whole tests don't take much time to write is bullshit. There are always things to configure in the test framework and something to go wrong. Plus you actually have to write the tests.

What kinds of things do you configure ? For us, the test environment is the same as the development environment, only we don't send out emails. Then there are some test scripts, but those are provided by Symfony and remain unchanged. So there is very little to setup.

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.

collyw is right. “Tests don’t take much time” is bullshit. Testing a feature typically takes as long as writing the feature, whether you pay that cost with unit tests, end-to-end tests, or ad hoc testing. (As hoc actually costs less up front but eventually many times more over the life of the product.)

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.

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.

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.

> takes no extra time

> invested heavily

pick one.

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

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

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.

If you're talking about emulating browser requests by tests you are already at integration tests territory.

Oh, I guess you're right. I may have interchangeably used unit-tests and integration tests because in PHP/Symfony, they look pretty much the same: some setup code and "assert()" calls.

Sorry for any confusion for anyone reading my previous comments.

You can isolate your server code behind an interface that lets you test it in your IDE, using the same requests that would normally originate in the browser. You just translate each browser request into an API call, and test that API call. No browser needed.

Cake + Eat-it, too.

Reply on news.ycombinator.com