41–50 of 76 posts
Write tests for things that you work on.
If it’s valuable, and you are a productive team member, you will eventually be able to convince other to adopt your practices.
The best way to convince people to test is to show its valuable by finding/preventing bugs.
Earlier quoted context omitted.
> It takes a while to get into a code base and really understand it, and by that time some things that seemed terrible or confusing at first will make sense. Classic Stockholm Syndrome.
Some call it stockholm syndrome, we call it the Spotify model!
Unless you've been brought in as leadership to turn things around, better to run far and fast. Working without sufficient tests is, from my experience, the easiest way to get 1 month of work done in 6. This will also affect your personal skills development and your outlook on how effective teams work. Get out before it infects you too.
Earlier quoted context omitted.
Totally agree with all your points except >there's not a lot of empirical evidence to support claims that automated tests will improve developer productivity or code quality. If you'd have said "there aren't any published papers _proving_ this" I would've agreed simply because I do not know if such studies exist or not (they might); but I'd argue that automated tests obviously improve code quality and productivity. A…
It's so obviously self evident that automated tests improve productivity, especially for developers new to a codebase. A developer makes a non trivial change. How do they know nothing broke? If there are no tests, they must spend an inordinate amount of time learning the entire system / product to gain any confidence they didn't break something, only to likely miss something that a senior team member will point out.…
It is not obviously self evident to me.
You should first establish yourself as a productive member of the team. No one is going to want to hear about how they could do things better from someone who just started. Once you have credibility and maybe some allies you'll want to have some evidence to support any new processes or workflows. Anecdotes about how you did things at other jobs won't carry a lot of weight. The problem with software development techni…
A more tactical thing is to actually do some work. You said that they don't have a style guide. Create one which you personally use and share it with your immediate team so that your own lives are better. Your immediate manager and team mates will have to work with you and if you start doing things which make your work obviously better, they'll pick up and that will give you mileage in the long run.
Automated testing is hard in practice when there are a lot of external dependencies and when there's a huge legacy codebase. This is a case by case thing but just like before, if you have something to show and the respect to buy attention, you might be able to sell an idea to them.
Earlier quoted context omitted.
It's so obviously self evident that automated tests improve productivity, especially for developers new to a codebase. A developer makes a non trivial change. How do they know nothing broke? If there are no tests, they must spend an inordinate amount of time learning the entire system / product to gain any confidence they didn't break something, only to likely miss something that a senior team member will point out.…
This assumes the tests are mostly valid. My experience in recent years has been that they won't be.
It's just odd to claim it's somehow ~unclear that automated tests aren't good for productivity. Forget the extremes (over testing, too many unit tests vs integration, potential rigidness): tests done right are productivity multipliers.
And that's not a "No True Scotsman" retort because the original claim had no qualifiers, and was suggesting that any version of automated tests are orthogonal to developer productivity. All you must do to refute that is think of any codebase you were able to make progress on faster because a test told you what was wrong faster than it'd take you to blame source code and send an email to a developer you maybe have never met yet.
Just do what you need to do in order to be productive. If that means writing tests, do it. It doesn’t matter if there’s CI in place. Maybe only you run the tests on your local machine occasionally. Just do it. Testing is a part of software engineering and you don’t have to ask permission to do your job.
Aside from what Flankk suggested about being one with the tribe: while you're waiting for your tribal acceptance card, measure the problem in silence. The change defect rate (how many percent of your commits are made to fix a problem introduced in an earlier commit) is very easy to sample manually, and gives you an idea of the scale of the problem. Then you can go to the team and say, "Look, 40 % of the things we do…
OP already has his mind set: *This must lead to a lot of problems which I'll only face after ramping up, but even onboarding is painful if you don't have e.g. clear automated testing set up.*
He just KNOWS that it MUST lead to a lot of problems.
I am fighting with this mindset at my work and I am sick and tired because people who KNOW - don't show any measurements.
Even if do measurements that in reality those unit tests of crud are waste of time I will be shot down by "that is what professionals do", while we basically have 0 defects because of backend code. While all the issues are on the frontend because of css/browser.
Find a new job. Don't try to fix cultures, you can't.
This is not true. People who fix cultures are called "leaders" and the good ones do it every day, little by little. Chisel at the marble slab and eventually you'll sculpt a masterpiece.