Hi, I normally contract in MSBI, Oracle, .Net/.Net Core, focusing on a property platform at the moment. Have also been working hard on upgrading my limited company website too.
Is it? Truly? In practice or theory? One thing I have gotten more into is "the code that writes the code". It then becomes more about how the application is configured and set up than developed.
Honestly. I think unit testing is a paradigm shift in many circumstances, it just concerns me when we have umpteen layers all needing unit test coverage.
The database.
JavaScript.
The Server Code.
The configuration.
The endpoints (controllers, api controllers).
Domain examples, users, workflows, etc.
Not challenging your experience, just asking whether it is as beneficial for these scenarios? Maybe write a post with examples on how you achieve gains doing this? I wrote this in response to a great post by @sharpninja
Kent Beck's book on Test Driven Development is a good place to start on this subject.
I think in terms of the things you've mentioned we're beyond the scope of pure unit tests. You'd have to do a lot of mocking, and dependent on what is under test they'd need to be backed up by integration tests to generate confidence. So I agree with you in many ways.
The reason unit tests, and TDD in particular, help with code design is because they push you towards code isolation. They drive you to abstract domain logic away from I/O and orchestration, because the code becomes easier to test. This also reduces code complexity, makes debugging easier, and increases confidence.
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.
Is it? Truly? In practice or theory? One thing I have gotten more into is "the code that writes the code". It then becomes more about how the application is configured and set up than developed.
Honestly. I think unit testing is a paradigm shift in many circumstances, it just concerns me when we have umpteen layers all needing unit test coverage.
Kent Beck's book on Test Driven Development is a good place to start on this subject.
I think in terms of the things you've mentioned we're beyond the scope of pure unit tests. You'd have to do a lot of mocking, and dependent on what is under test they'd need to be backed up by integration tests to generate confidence. So I agree with you in many ways.
The reason unit tests, and TDD in particular, help with code design is because they push you towards code isolation. They drive you to abstract domain logic away from I/O and orchestration, because the code becomes easier to test. This also reduces code complexity, makes debugging easier, and increases confidence.