4 ms·

Going from "manual testing" to automated testing is the biggest jump. Unfortunately, lots of folks (both developers and managers) fall into the trap of thinking

Going from "manual testing" to automated testing is the biggest jump. Unfortunately, lots of folks (both developers and managers) fall into the trap of thinking they will "use up" their development time on automated tests, and not really thinking how much time they're already wasting just to do (incomprehensive and hand-wavy) manual tests each time. And while this strategy might work for the folks who actually wrote the code (and thus have tacit knowledge about it), the moment they leave and/or someone new joins the team, all that "speed advantage" is lost and it turns from minutes to hours to days instantly. Automated tests really are the only way to capture the business logic of any code for it to not to become "legacy code" before its time.

cjfd 5y ago
Very good points. In his book 'working effectively with legacy code' Michael Feathers actually defines 'legacy code' as code without tests. Largely because of reasons like you state.
- vbezhenar 5y ago
  What do you think about code being too smart for current team? I encountered that use-case three times in my career. It was C++ program which was written by very bright person, used template magic, boost and stuff. Rest of the team were ordinary C developers. After that person left, they had to rewrite his program, because it took too much time to understand how it works and to fix or improve it. Second case was when someone wrote some helper program with Haskell which happened to be important. Same story, nobody knew Haskell, nobody wanted to invest into learning, so rewrote in node.js. Third story: someone used reactive API with Java (Spring Flux) and again same story: team don't understand it and slowly rewrote it with ordinary blocking API. Does that code counts as legacy?
  - hu3 5y ago
    This is where Go shines in my opinion. It's really hard to write smart Go code. Sure it is a bit verbose but dam is it easy to understand due to sheer bluntness and lack of magic.
  - marquis_andras 5y ago
    Michael Feathers uses several definitions of legacy code, depending on the situation. In your situation, he defines legacy code as follows. "legacy code is the product of ... when your team turns over faster than your code turns over." [1] 1. https://www.software-engineering-unlocked.com/legacy-code-michael-feathers/ https://www.software-engineering-unlocked.com/legacy-code-mi...
    - dotancohen 5y ago
      Those two definitions just sold the book to me. Thanks.
- dinvlad 5y ago
  That's where I borrowed that term as well :-)
KronisLV 5y ago
> Unfortunately, lots of folks (both developers and managers) fall into the trap of thinking they will "use up" their development time on automated tests, and not really thinking how much time they're already wasting just to do (incomprehensive and hand-wavy) manual tests each time. Actually, currently am about to be asked when the feature will be done, whereas i've decided to actually write tests for it (reusable library code across multiple projects). As far as the reality is concerned, the people who say that writing tests "uses up" time are right: being slow now will be more visible than no one understanding why development takes a whole lot of time down the line, which is when many might just shrug their shoulders and go "legacy code". What's the benefit of making others able to develop code faster, if that makes you be slower - both facts probably being visible to management, though oftentimes without the underlying reasons behind those being relevant to them? I'd argue that that's why even governmental projects in my country (that are often contracted out to random companies) oftentimes have poor test coverage and just generally not a lot of thought is put into the quality and sustainability of those codebases - they got paid, they could iterate reasonably quickly while the contract was ongoing, why should they worry about anything? The people who take over the project then can also deliver features more slowly, not only because of the poor domain understanding, lack of ADRs, lack of documentation, but also lack of tests - and still often get paid on a time material basis. Thus, no one actually wants to improve things, apart from me wanting to tear my hair out whenever i'm expected to work on garbage like that and fix their problems. Thus, you see some people in the industry adopt an egoistical approach to it all - join a company, focus on the speed of their own iteration without thinking about the project in the long term, spend a few years doing this and then leave for another company where they'd do the same thing. It might be a cultural thing, but working on other people's projects instead of starting my own feels like losing at this point - no READMEs, no automated CI, no Ansible, no Dockerfiles, no IDE run profiles, no common linting rules, no code static analysis, no local DBs with migrations, no local setup scripts etc. Why should i be expected to toil away without results that are visible to the business because someone else was allowed to neglect the codebase? At this point, i use unit tests and code coverage rules defensively: to prevent someone from jumping into the project and ruining how things should work with breaking changes, which will be caught by the tests, or by introducing untested and undocumented code, which the coverage rules will catch and make CI fail. Of course, depending on the culture, you might find that other devs talk amongst themselves and before long your tests have @Ignore added to them or have been removed entirely, which is the point where it might just be easier to look for a less dysfunctional environment, despite living in a country that others outsource to and therefore quality isn't a priority. In short: i agree with your point, but i think that there are social problems at play. You need to actually care about the code that you're developing to prevent these issues in the long term. And even then, if you care, that doesn't mean that other team members will.
withinboredom 5y ago
I agree. The issue is when you don’t have the test harness or the code just isn’t testable. Then it really will “use up” your dev time for not much gain. Or at least it’s a harder sell. My “dark pattern” to sell this is to offer to refactor a small portion at a time, then read through as much code as I can on nights/weekends looking for unhandled edge cases. When I find one, that’s the part I make tests for. Wo and behold, it found bugs! Bonus points if the edge case actually causes issues in prod or loss of revenue. The manager is now convinced we need this thing, or at least thinking about giving us time to work on it.
wruza 5y ago
This is where I stop understanding modern ui frameworks. Instead of making an ui inner machinery (controllers) as a set of modules which could in theory run even in a non-browser environment, they pile up everything together into dom/etc. UI could be just a thin layer over usually testable ui-controllers, whose methods could be called by either controls or offline test suites (as in most desktop frameworks). But nope, they do mountains of “smart” views and test them instead as a whole. …I just googled for “React TDD” and the top no-money result suggests finding divs in containers and spying on dom changes. It’s like testing your cli app by hooking into tty driver’s section in /dev/mem.
- dotancohen 5y ago
  For what it's worth, a popular Python testing framework uses something like `expect` under the hood to simply check that the output matches a predefined output.
- Vinnl 5y ago
  Interesting, in my experience React allows me to write more testable code in the front-end than I ever could. Given how React will handle updates to the DOM given changed state, I can extract complex state manipulation code (i.e. code that's most important to test) into independent functions that take state and an event and produce new state, rather than having that all intertwined with DOM manipulation code. And when it comes to testing what your DOM looks like, even though that does often involve spying for changes (after all, you're testing whether they occur), that's not on the actual DOM but on the virtual DOM, which makes it easy and efficient to run in a non-browser environment.
- Too 5y ago
  This is how both Vue and Angular work. You have a “data” as a model sitting between the DOM and the controller (mainly methods and watchers). There are some gray lines, like computed properties, but otherwise the controller can run without the DOM and vice versa, you can easily force the model into a state to see how the view will look like. A lot more testable than the old spaghetti of onClick and getElementById().addEventListener.
fbn79 5y ago
No if you delegate manual tests duty to your customers shorturl.at/mpxS4
- mschuster91 5y ago
  Your shorturl is broken, also please don't use URL shorteners in here.

cjfd 5y ago

Very good points. In his book 'working effectively with legacy code' Michael Feathers actually defines 'legacy code' as code without tests. Largely because of reasons like you state.

vbezhenar 5y ago
What do you think about code being too smart for current team? I encountered that use-case three times in my career. It was C++ program which was written by very bright person, used template magic, boost and stuff. Rest of the team were ordinary C developers. After that person left, they had to rewrite his program, because it took too much time to understand how it works and to fix or improve it. Second case was when someone wrote some helper program with Haskell which happened to be important. Same story, nobody knew Haskell, nobody wanted to invest into learning, so rewrote in node.js. Third story: someone used reactive API with Java (Spring Flux) and again same story: team don't understand it and slowly rewrote it with ordinary blocking API. Does that code counts as legacy?
- hu3 5y ago
  This is where Go shines in my opinion. It's really hard to write smart Go code. Sure it is a bit verbose but dam is it easy to understand due to sheer bluntness and lack of magic.
- marquis_andras 5y ago
  Michael Feathers uses several definitions of legacy code, depending on the situation. In your situation, he defines legacy code as follows. "legacy code is the product of ... when your team turns over faster than your code turns over." [1] 1. https://www.software-engineering-unlocked.com/legacy-code-michael-feathers/ https://www.software-engineering-unlocked.com/legacy-code-mi...
  - dotancohen 5y ago
    Those two definitions just sold the book to me. Thanks.
dinvlad 5y ago
That's where I borrowed that term as well :-)

KronisLV 5y ago

> Unfortunately, lots of folks (both developers and managers) fall into the trap of thinking they will "use up" their development time on automated tests, and not really thinking how much time they're already wasting just to do (incomprehensive and hand-wavy) manual tests each time. Actually, currently am about to be asked when the feature will be done, whereas i've decided to actually write tests for it (reusable library code across multiple projects). As far as the reality is concerned, the people who say that writing tests "uses up" time are right: being slow now will be more visible than no one understanding why development takes a whole lot of time down the line, which is when many might just shrug their shoulders and go "legacy code". What's the benefit of making others able to develop code faster, if that makes you be slower - both facts probably being visible to management, though oftentimes without the underlying reasons behind those being relevant to them? I'd argue that that's why even governmental projects in my country (that are often contracted out to random companies) oftentimes have poor test coverage and just generally not a lot of thought is put into the quality and sustainability of those codebases - they got paid, they could iterate reasonably quickly while the contract was ongoing, why should they worry about anything? The people who take over the project then can also deliver features more slowly, not only because of the poor domain understanding, lack of ADRs, lack of documentation, but also lack of tests - and still often get paid on a time material basis. Thus, no one actually wants to improve things, apart from me wanting to tear my hair out whenever i'm expected to work on garbage like that and fix their problems. Thus, you see some people in the industry adopt an egoistical approach to it all - join a company, focus on the speed of their own iteration without thinking about the project in the long term, spend a few years doing this and then leave for another company where they'd do the same thing. It might be a cultural thing, but working on other people's projects instead of starting my own feels like losing at this point - no READMEs, no automated CI, no Ansible, no Dockerfiles, no IDE run profiles, no common linting rules, no code static analysis, no local DBs with migrations, no local setup scripts etc. Why should i be expected to toil away without results that are visible to the business because someone else was allowed to neglect the codebase? At this point, i use unit tests and code coverage rules defensively: to prevent someone from jumping into the project and ruining how things should work with breaking changes, which will be caught by the tests, or by introducing untested and undocumented code, which the coverage rules will catch and make CI fail. Of course, depending on the culture, you might find that other devs talk amongst themselves and before long your tests have @Ignore added to them or have been removed entirely, which is the point where it might just be easier to look for a less dysfunctional environment, despite living in a country that others outsource to and therefore quality isn't a priority. In short: i agree with your point, but i think that there are social problems at play. You need to actually care about the code that you're developing to prevent these issues in the long term. And even then, if you care, that doesn't mean that other team members will.

withinboredom 5y ago

I agree. The issue is when you don’t have the test harness or the code just isn’t testable. Then it really will “use up” your dev time for not much gain. Or at least it’s a harder sell. My “dark pattern” to sell this is to offer to refactor a small portion at a time, then read through as much code as I can on nights/weekends looking for unhandled edge cases. When I find one, that’s the part I make tests for. Wo and behold, it found bugs! Bonus points if the edge case actually causes issues in prod or loss of revenue. The manager is now convinced we need this thing, or at least thinking about giving us time to work on it.

wruza 5y ago

This is where I stop understanding modern ui frameworks. Instead of making an ui inner machinery (controllers) as a set of modules which could in theory run even in a non-browser environment, they pile up everything together into dom/etc. UI could be just a thin layer over usually testable ui-controllers, whose methods could be called by either controls or offline test suites (as in most desktop frameworks). But nope, they do mountains of “smart” views and test them instead as a whole. …I just googled for “React TDD” and the top no-money result suggests finding divs in containers and spying on dom changes. It’s like testing your cli app by hooking into tty driver’s section in /dev/mem.

dotancohen 5y ago
For what it's worth, a popular Python testing framework uses something like `expect` under the hood to simply check that the output matches a predefined output.
Vinnl 5y ago
Interesting, in my experience React allows me to write more testable code in the front-end than I ever could. Given how React will handle updates to the DOM given changed state, I can extract complex state manipulation code (i.e. code that's most important to test) into independent functions that take state and an event and produce new state, rather than having that all intertwined with DOM manipulation code. And when it comes to testing what your DOM looks like, even though that does often involve spying for changes (after all, you're testing whether they occur), that's not on the actual DOM but on the virtual DOM, which makes it easy and efficient to run in a non-browser environment.
Too 5y ago
This is how both Vue and Angular work. You have a “data” as a model sitting between the DOM and the controller (mainly methods and watchers). There are some gray lines, like computed properties, but otherwise the controller can run without the DOM and vice versa, you can easily force the model into a state to see how the view will look like. A lot more testable than the old spaghetti of onClick and getElementById().addEventListener.

fbn79 5y ago

No if you delegate manual tests duty to your customers shorturl.at/mpxS4

mschuster91 5y ago
Your shorturl is broken, also please don't use URL shorteners in here.