…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.
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.
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.
Does that code counts as legacy?
"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-mi...
Sure it is a bit verbose but dam is it easy to understand due to sheer bluntness and lack of magic.
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.
From my limited experience, governmental projects tend to have the worst code quality ever. At least that's what I see here. It can easily be explained by pervasive corruption — projects go to those who agree to return the largest kickback and are written mostly to steal money from the taxpayers. With such incentives, code quality does not receive much attention.
You hit the nail on its head here, my friend.
When working with others' projects, I try to add tests where I've added/modified features, so that at least I can get a sense of it all and make sure I don't break anything. And for a completely untested codebase, it might make sense to add more integration-like tests (while still using mocks for external dependencies), such that simultaneously a bigger proportion of the codebase is covered, even if at slightly longer test times.
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.