4 ms·
I am not qualified enough to say if it is dysfunctional, however a big red flag to me is when your CTO says he "doesn't want git to be polluted". My first piec
by TheBiv 12y ago
I am not qualified enough to say if it is dysfunctional, however a big red flag to me is when your CTO says he "doesn't want git to be polluted".
My first piece of advice would be to go into his office and very respectfully ask him to unpack what he meant by that statement. He may have just been trying to say that you were too junior, he doesn't believe that unit tests are worth the business advantage, or any number of things.
The reason I suggest this as a first step is because it will open up the communication between him and you over something that may give you more insight as to why he would say such a statement that is so grossly over exaggerated to the point of being a lie.
The theory would then go that if you could get your CTO to open up about this subject, then they are going to be more likely to open up to about other suggestions regarding the development process/other operational efficiencies.
- viredfox 12y agoI 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 agoThat 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 agoSelenium 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 agoOne 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 agoWrite 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 agoPart 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 agoFWIW 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