After months of learning Ruby and writing stuff on my own, I’ve finally got a full-time job in Ruby. Yay!
Since I first learnt Ruby, I’ve been writing tests and, most of the time, following the TDD approach. I’ve find it so useful that I can’t imagine not writing tests. However, I’ve landed in a company with 0 culture of TDD, or even tests at all. They don’t test anything. Nothing. Zero.
We’re about to take a very large and complex project, and I’m pushing so we write tests. I’ve told about the benefits of it, but the answer is always “we have no budget for that, so we should ask the customer if she wants to pay for tests too”, or “we must be productive”. Luckily, the other developer thinks we should write tests, too, eventhough he has no experience at all, which also is used for my boss as an argument not to test, since that would mean even more hours to budget.
I’m looking for guidance. Any advise on how could I help my company to have a testing culture? Quite an open question, I know, but any comment is appreciated.
Thank You.
PS: I should add that I’m trying to convince my boss so at least we write Model and Integration tests
Hey. The same thing happened to me. You can never convince your boss for adding TDD approach to the culture. The more you try to convince him the angrier he will get.
What you can really do is write specs only at your level without telling anyone about it. This way no one will know abt the specs since they won’t be even touching it. Also, try adding integration specs to the features you work on.
Now suppose some other developer changes something but the specs fails and you are able to debug the problem in time then you can show it your boss the benefit this saved on the debugging time.
This way you can start slow and steady. Don’t rush into changing the culture. It takes time to change a culture and words don’t have any impact anyway.
Thank you very much Charlianna and Ben for your comments. In fact, I took the first approach in a project that was assigned to me, and I’ve managed to write tests while still keep in budget. I yet have to tell my boss about this However, I’ve had nothing but good words about the result, so I guess that helps a little bit.
On the other hand, something cool happened today after I wrote this question. The manager called and said he liked what I said about testing, and he’ll assign to me a massive rewrite of a legacy code that is key to our business. So… it turned out quite good, after all!
I might follow the advice on the thread that Ben linked to and try to work out some examples from our current code base or even organize a pairing TDD session.
This is a pretty hard spot in fact. I recently went in to a very long running codebase, with hundreds of tests. They fail to a total of 265, always slightly different. Some fail with undefined class Rails… And I was implementing changes to payments. (!)
My point here is that you need to push for a mindset change. People can get on board with a dev writing tests and “not loosing productivity” but unless everybody gets invested, you end up in a terrible situation: one that Katrina Owen perfectly describes as “everyone defecting”.
Keep pushing, you are fighting the good fight. Pair while TDDing, highlight the options it enables you to take (without being too “preachy” ) and you’ll get people on board
This is basically what happened to me on my first rails job. The company wasn’t against testing, it’s just no one was really doing it, probably because I don’t think there was anyone who really knew how.
Like you, I had been exposed to testing and had it drilled in to my head from the material i used when I learned rails. I just started writing tests without saying anything and eventually it caught on with some of my coworkers. Sounds like it’s working out for you quickly. I definitely recommend the outside-in workflow videos on upcase if you haven’t seen them already.
Thank you Ben and Evan. I’ve seen the latest, and I can’t quite remember if also the former, so I’m going to rewatch it
What I’m seeing here is that my situation is more common than I thought. Maybe because I got into Ruby through online schools, manuals and Open Source, I had developed the fantasy that Ruby companies where places where everyone was into best practices, doing OS in work hours, and doing all sort of marvellous things, hahahaha.
I think this is just a developer to management communication “API” issue. What you think your are saying gets translated in the manager mindset as being an “additional amount of work” in the project. The reality is that everyone tests their code in their own way; TDD just happens to be a better way. What we are talking about with TDD is automated testing rather than poking around in a debugger, echoing text between lines of code, and hard coding magic values to see how things work.
I really don’t think its necessary to bring up the issue because management cares about shipping a product that makes customers happy, on-time, and in budget. They do not care about how you go about making this happen. Unless you are one of the few unfortunates who has a technical manager who will actually check and see if you wrote tests, just get the product developed in that way that works best for you. Likely, it will involve using TDD methodology and as long as your on-time/in-budget no one will care.
Culture change happens by example, not by debate. Its always easier to ask for forgiveness, after a successful project, than to ask for permission to begin with.
tl;dr: Do it anyway, tell them after its successful, or don’t.
Yes! I hadn’t thought of that, but it’s how it is. In fact, after every change we spend time checking things in the browser, first on staging, then checking in again on production, and at the end of the process so much extra time and energy is wasted.
I have yet to see where this goes as a team, but I’ve started doing my thing. However, since no one but me knows how to write tests, I guess it’ll take some time. But at least the manager has no oposition to TDD; they’ve just never done that, and don’t even know how to do it, but he told me that I do what I think it’s best.
Continue work on your own personal
side projects using the best practices, including TDD.
Start searching for a new job.
From years of experience, I can tell you that you will not win the TDD war with your boss. Instead, you’re going to be resentful and not happy over the long term. We could find lots of clever ways to convince this boss, but ultimately if a company needs to convince a client as to the value of tested code, then that might not be a company worth working for because it sounds like the culture of the company is “speed” and “lower cost” as opposed to quality. Ironically, TDD actually lowers costs over the long run, but many companies don’t get that. They prefer to front-load profits and then re-charge a client a ton of money to make changes down the road (changes that would not have been painful if TDD were used.) In my opinion, those are scumbag companies because they care more about screwing the customer rather than building long, meaningful relationships. You also likely have a so-called “QA” department that they charge the client for as well. TDD will reduce the justification of a dedicated QA and thus potentially reduce the additional “value-adds” the company can charge the client.
I know I wasn’t much help, but hopefully you can find some peace! Good luck!
Hey Brian. Thanks for your frankness. In fact, I think that’s the most likely scenario, too. As you say, there’s an underlying problem here, which is the quality of the software. Even if I’m still an intermediate level developer, I care about quality, and quality and tests go hand by hand. I feel that I can’t grow as a professional in such an environment, so even when it’s hard to find a job being a Jr/Intermediate developer, I guess I’ll have to move soon.
However, I’ve had nothing but good words about the result, so I guess that helps a little bit.
) and you’ll get people on board
Seriously, I’m glad you asked your question.