Hey everyone!
First of all, thanks Dev.to! This is an amazing community and I'm glad to contribute a bit with my first article.
Recently in my company we are migrating our monolithic Meteor application into a Microservices architecture. Our services are mostly express apps and I'm trying to encourage testing since the beginning, with a focus now on integration testing. My approach is to use supertest to test the API surface of our services and nock to mock requests to external services (first party or third party). In my opinion, this makes developing a service in isolation just by assuming the contract between the service under development and those forming the environment is right. It allows you to execute your code without requiring other services to be running, which I'm my opinion is a must in such architecture.
I have to convince them. Do you think those arguments are enough? Any tip?
Thanks in advance!
Oldest comments (14)
One of the easiest ways to convince people is to simply do it, if you can get away with it.
Once they see how much easier it is to refactor something or to tell where a problem came from, others will ask you and follow your approach.
You probably shouldn't write tests for all existing code at once, but instead you can develop your next feature by writing tests first. Developing TDD-style often takes only minimal more effort and leads to a more robust and thoughtful solution.
It's always good to frame the benefits of something in terms of things they already care about. Testing is huge for having confidence in making future changes, long-lasting iteration speed, etc. Frame things in terms of what already motivates them.
I'll also add that automated static analysis tools which grade you on certain testing metrics can be great at encouraging people to actually follow through. If you're not already using something like this, I'd recommend it. We use Code Climate. They can be integrated into your git flow and really help maintain accountability and also make improvements more fun. Metrics can and will be over-optimized for so they're a supplement, not a replacement to, good old fashion clean coding.
In other words, to establish solid reliability in production tomorrow we need to invest our time today. Your need for tests for your current project depends on:
return True if team.size > 1 else False. Having more engineers means more views on the same items. Tests help to document the opinions how a class or function can be used.return True if project.modules > 1 else False. You can't remember the color of socks that you wore two days ago. Can you remember everything in the project?I published a blog post on Dev.to() on the topic recently:
No Tests - No Pull Request, Right? Types of Tests that Should Be in Your Codebase.
It might help you yo convince your teammate.
Write tests for your own new code; write tests for the legacy code you need to amend and keep being that never ending pain-in-the-ass noise about testing.
Some day, some of your services will roll out to production with some serious bug (then rolled back, fixed etc...). Seize that opportunity to write a unit-test for that very bug and gather your colleagues and let them see what little piece of code could have prevented. If they are not convinced, financial matters will be enough to convince management.
Similar to other comments:
What if you reverse the approach?
Pick an arbitrary project, find a bug and show them how easily is to break the cooperation of these services because of the lack of testing. It might take you a little bit of time to write one or two examples but they could be a good use case to present as your argument for automated testing.
It's relatively easy to convince people that testing is important. It's much harder to convince them to actually write tests. That's the problem. :( And it is even harder to convince developers, that unit testing is their job, even when there are dedicated QAs in a team. And the next step is actually to teach the to write correct unit tests, because if done incorrectly, you will be the one to blame for the failure of "unit testing", even if it is not you, who did the wrong thing.
So I wish you good luck. That's very thorny way, but it is a right way.
(I'm on a "teaching" stage myself. :) )
Thanks for all your replies!
I'm already writing tests, and I've been also pushing this for long. To some extent, a lot of devs accepted that testing is important, but it's also important to know
whatandhowto test.The problem right now is that our microservices are still pretty dumb, and they don't see the value of adding those integration tests. My main argument now is that you can't really run your code if you don't have tests in such an architecture because you'd need all the other services to be running, which is a no-go. I'll focus on that point for now
I don't like that unit testing requires to restructor code or even mocking.
It's like testing stuff that wouldn't be there to test in the first place. :/
In our case, mocking the network makes sense IMO. You are writing a service that connects with other services, but you don't want to run the whole infrastructure while developing that service. We stub the responses coming from other services using
nock.I agree with you that mocking a lot of stuff for unit testing is a code smell. But in our case, this is an integration test for the whole service itself.
Teaching by example should be effective - a small, elucidating example. If possible you should try to put together a 15 minute meeting with the developers and TDD-out a small feature live on a big screen. Or the next time a relatively small bug crops up, write a test by yourself that reproduces it and show the team how you fix it live turning that test green and fixing the bug at the same time.
I think once people witness live and first-hand how painless TDD makes designing and shoring up a new feature they will want to do it on their own. There is definitely a non-negligible learning curve though, so immediate adoption isn't likely.
For instance, I am pretty strict with TDD in my own comfort zone tech (Ruby, Rails) but even though the paradigm is the same I haven't yet taken the time to learn the testing tools around JavaScript so the idea of testing js scares me. I'm someone who is already fully on-board on the testing train and practice it personally, but testing in a "new" language is an impediment to me, so I can fully understand being resistant to the new idea of testing at all.
be patient and sell it!
I've personally never seen anyone convinced to be diligent about testing simply by being convinced. They may even nod and agree with you, but they're not going to actually change the way they work.
The one and only way to go is to lead by example. And it's going to take a long, long time for the team's culture to shift. In my experience, expect it to take at least 2 to 5 years.
The only way to speed it up is to get your manager, PM, and team lead to actually measure testing and test coverage as part of how they measure team performance and code health.
And along the way, you're going to lose momentum every time anyone has a negative experience that they feel is because of the testing.
"I just made a little change and all these tests broke! My code is fine! Why do we even have these stupid tests?"
"I came in early to get my code rebased and merged, and the project won't build until I update my IDE and run npm and get theses tests running, and they're not even my tests! ARRRRRGH!"
"Why are we slipping deadlines? We'd be on schedule if we didn't spend time writing tests. Isn't that QA's job?"
So. Go slow. Make absolutely sure that living with tests is a positive experience for everyone. Any time someone asks you about them, be the calm voice that says everything is going to be wonderful.
The absolute kiss of death is if your manager feels you're diverting the team's energy away from the business's goals and toward your own. You're manager gets a bonus for hitting various KPIs. If your manager feels you're hurting their chances of hitting those KPIs, they will feel you are going rogue and literally taking money out of their pocket and hurting the team's performance in the service of your own idealism. (And they're not entirely wrong.)
So, unless you have enthusiastic support from your boss, tread lightly, persuade gently, show everyone the way, and let them come follow you when they're ready.
Be patient. And good luck!
A little late to the discussion, but I'd throw out that writing tests for certain types of code will help you write the code faster.
Anytime you have a function that consists of various conditionals, unit testing is great to help your mind keep clear all the different outcomes that function can return.
I would actually skip writing tests for a simple function that doesn't have much "logic" in it. If it's a simple 2+2 calculator, a test isn't going to be all that valuable.
The concept of a "flow state" can really play in. The great thing about TDD is that, in the right settings, you can really get that immediate feedback on whether your code update worked or not.
Every time you get a test to go green, your brain gets a hit of success. Repeat this and you can really have fun with writing the code.
The best way to do convince your team is to just do it.
Start sneaking in automated tests into the code base, and then keep telling your team members during breaks about how you can just chill because you've got automated testing. ;-)
Appealing to peoples' emotions works much better than stuffing facts about the benefits of automated testing in their faces.
Everyone wants to go home and have a good nights' sleep right?