Front end developer specialising in JavaScript and React. Experienced in all aspects of modern front end development. Passionate about making accessible, secure and performant software.
I think I spend sufficient time writing tests. Testing is the same as writing good code. It's a balance. You don't want your code too dirty, or overengineered. You want it to be a relatively simple solution for what you need today, that is easy to work with tomorrow. That's a sweet spot somewhere between too dirty and overengineered (perfectly decoupled).
In terms of tests: Tests provide confidence, but they cost time (both to write the actual test and to change it later if you make certain code changes that require the tests to also change). There is a sweet spot where they provide maximum value. Building a toy front end app? A little confidence is sufficient. Building a life-critical application? You want maximum confidence, doesn't matter if writing the code takes 4x as long as it would with no tests (or just a few tests).
For something like an ecommerce app or your average commercial project, you want pretty good confidence that everything works. That means that sometimes you only need a few tests cases and other times you need many. In general, I'd say 25% to 50% of my time is spent writing tests. This includes unit, integration and end to end tests.
That time is reclaimed because I don't have to spend as long debugging while writing code, or fixing past bugs. Better yet, there are less critical bugs that cost the company money.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think I spend sufficient time writing tests. Testing is the same as writing good code. It's a balance. You don't want your code too dirty, or overengineered. You want it to be a relatively simple solution for what you need today, that is easy to work with tomorrow. That's a sweet spot somewhere between too dirty and overengineered (perfectly decoupled).
In terms of tests: Tests provide confidence, but they cost time (both to write the actual test and to change it later if you make certain code changes that require the tests to also change). There is a sweet spot where they provide maximum value. Building a toy front end app? A little confidence is sufficient. Building a life-critical application? You want maximum confidence, doesn't matter if writing the code takes 4x as long as it would with no tests (or just a few tests).
For something like an ecommerce app or your average commercial project, you want pretty good confidence that everything works. That means that sometimes you only need a few tests cases and other times you need many. In general, I'd say 25% to 50% of my time is spent writing tests. This includes unit, integration and end to end tests.
That time is reclaimed because I don't have to spend as long debugging while writing code, or fixing past bugs. Better yet, there are less critical bugs that cost the company money.