5 ms·

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 lea

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.

TheBiv 12y ago
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!
- viredfox 12y ago
  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"
  - pfitzsimmons 12y ago
    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.
avelis 12y ago
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)
- viredfox 12y ago
  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)
  - strlen 12y ago
    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/ 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.
  - thomasvendetta 12y ago
    > Part of the problem is that I'm not THAT good. Not with that attitude, you're not :)
  - Kaizyn 12y ago

TheBiv 12y ago

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!

viredfox 12y ago
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"
- pfitzsimmons 12y ago
  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.

avelis 12y ago

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)

viredfox 12y ago
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)
- strlen 12y ago
  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/ 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.
- thomasvendetta 12y ago
  > Part of the problem is that I'm not THAT good. Not with that attitude, you're not :)
- Kaizyn 12y ago