Hacker News Reader

Comment by viredfox | Hacker News Reader

I actually talked with the CTO (not directly related to that), but I believe he doesn't think unit test is a worthwhile investment at the time. From what I learned, I don't think he has ever worked in an environment with a strong culture for automated testing + CI.

View on HN

That is really cool that you began that dialogue!

Even though this is far from unit tests, were you allowed to suggest anything like Selenium? which would allow you to at least test the business facing functional points so that you could be sure that a release wouldn't break what the business person sees.

Just wondering if he is 100% against tests in all scenarios!

Selenium needs quite a bit more overhead than the unit test I'd be doing, so I think it's even less unlikely.

He is certainly not ideology against tests by any means, it's just he doesn't believe the trade off would be worth it (test writing time and debug vs time spend directly on development). My guess the answer would be along the line of "we're lacking resources"

One approach is to start documenting how much of your time is spent either a) manually testing changes because you have no automated tests b) debugging, fixing bugs, and patching messed up data due to bugs that easily could have been caught by tests. I find that investing in basic acceptance tests pays itself off very quickly. Good tests allow you to iterate on your early product much faster, because you can actually make changes without breaking things for your early users. If you can document the wasted time, maybe you can convince him of the benefit.

Write one test and use a CI rig to show how you can offload the testing in an automated fashion. (e.g. circleci.com, travisci.com, codeship.io, buildbox.io)

Part of the problem is that I'm not THAT good. I believe that there are a lot of things that can be fixed and/ or done better. And I'm fairly certain there are certain programmers that could do that, unfortunately, I'm yet to be a programmer of that capability. I can't keep up with both the expected work and trying to setup CI (to the extent that would demonstrate its usefulness)

FWIW You don't need to very good (or even write any code) to use travisci, it's very easy to do. You can start with just running basic compilation/lint checks: http://docs.travis-ci.com/user/getting-started/ -- just compiling/linting the code (to check for missing libraries, files you forgot to add to git, syntax errors, etc...) is _already_ useful. E.g., if you have a python codebase and never you never run pychecker or pylint (or if you have a php codebase and never run php -c or if you have a Java project and never build it entirely until release day...) you may be missing something that can lead to hours of downtime 4-5 weeks down the line.

If you're using a dynamically typed language I'd suggest very trivial (1-5 line) unit tests _just_ to test that you can instantiate the objects and catch basic type errors. If it's a web app, a simple script that starts a local instance and then make sures that retrieving "GET /" returns "200 OK" is again a huge improvement over _nothing_.

Overall, my/tlb's recommendation remains: be in a position where good programmers can offer you good feedback and where you're pushed to improving your own capacity.

> Part of the problem is that I'm not THAT good.

Not with that attitude, you're not :)

The only way you're going to get approval for "improving things" is if you can do both of the following: 1. Build a sound business case that shows that there is return on effort for the startup, and 2. Build a proof of concept that shows HOW it can be done in your environment. If you can't do both, then it will be fairly difficult to sell your company on your ideas for process improvement.

Rather than worrying about setting up CI all at one go, what I would suggest you do is structure your personal development workflow around some form of automated testing - either test-driven development or by just frequently running an integration and/or unit test suite. Keep the test code in a separate git repo and start out simply: setup a git hook script to execute the test suite locally after every time you run 'git pull'. From there, just build up the cleverness of your testing apparatus as you have time. If you start finding defects in other team members' changes incidentally as part of your work practices, that will prove the method in a way little else could.

You're definitely that good. I hear you, and I know exactly how this feels.

I've worked for two companies in the past year and a half, both with teams of ~5-10 developers, and nobody at either company was/is using any sort of automated tests. It's definitely frustrating -- not to mention lonely -- especially when you're immersed in a culture (hello HN) that's pimping a new test runner every two weeks.

I like testing for one and a half reasons: to capture the software requirements, and to change the software easily when those requirements change. If you've got one test, that's better than zero.

You don't have to set up your own Jenkins server -- Travis CI should do the trick nicely, and it's super easy to set up (although I know you're not supposed to say that kind of thing).

Here's a thought: Could you persuade the CTO to let you add the tests as a submodule to the project repo?

None of the cloud CI would work for us: we have an inhouse hosted git server (the CTO does not trust open source, in general). So to do automated testing, I'd have to set up a Jenkins server on my own.

That's strike two against him. Have you had the conversation with him about why he feels that way about open source?

The attitude about cloud services is more understandable, though inconvenient. However, I think you may be laboring under a misapprehension: You don't need to have a CI server to run tests automatically, you can have a test suite running locally and trigger it with a pre-commit hook (so you can't actually commit if a test fails).

Reply on news.ycombinator.com