Introduction
The first time I entered a company as a developer, I did it as a sort of full stack, more oriented to Front End than Back E...
For further actions, you may consider blocking this person and/or reporting abuse
Your headline of "stop doing component unit testing" is terrible advice. Testing small self-contained units is the best way of quickly detecting and finding regressions.
It just shouldn't be all you do.
Yes actually I recommend do it if the context requires that. What I mean is that, under my experiencie, an integration test should be in the first priority.
But this is a personal approach, this is not an absolutely truth.
Cheers!
This is exactly my experience, too. If you cannot afford to build full automated test suite with unit tests and integration tests, skip the unit tests.
Unit tests are nice because they will pinpoint the source immediately but they are rarely good enough and will not catch bugs from interactions between units.
Unit tests alone might work if you have 100% coverage and active mutation testing to verify that your tests test everything. I've never been in a team that could do that in real world.
Yikes. Please don’t skip unit tests. Test coverage is a progression and you make trade offs based on the quality of your tests. Unit tests have the lowest barrier in terms of creating confidence in your code.
Don’t skip testing. Just write better tests.
As I wrote, if you cannot write both unit tests and integration tests, skip the unit tests and write integration tests only.
Of course, having both is obviously better. If I could choose, every piece of software would have full test suite with 100% code coverage and mutation testing to validate the test suite. (Mutation testing is about testing the quality of the tests, not the program.) However, sometimes the employer wants to go with "good enough" implementation and take a risk with unknown bugs instead of paying for the test suite.
I’m the opposite. If you can’t write both, write unit tests. The feedback loop is just faster. Integration tests just require more complexity upfront. For me confidence is the currency, and unit tests just pay out sooner.
The title of the article should be "Stop doing ONLY component unit testing."
You should read about the testing pyramid.
In fact we need both small unit tests and large end-to-end tests as they cover different part of the system with different angles.
All those tests should pass all the time.
I was brought recently to a similar conclusion when building a Laravel + Inertia + Vue application. Inertia comes with a nice integration to write this style of test inside where a back end dev would expect to write their unit/feature tests. Essentially it blends the styles of Jest and PHPUnit and it was quite a nice and intuitive syntax to use.
After writing a couple I was like, "huh... these are much more 'simulating the user' type tests than I usually write for my server-side code" so I definitely see the value of adjusting your thinking when approaching test writing for components in Vue.
Wow, thanks so much, I'll investigate that tool, it seems really helpfull!
This video opened my eyes about unit tests.
Yes he talks about test driven development, but he explains the core concepts of what is a unit, what is a test and what a test should check.
youtu.be/EZ05e7EMOLM?si=oO_ohtTuG1...
A nice solution is cypress component testing.
I like the idea of testing components in a browser.
Totally, it is something that I am iterating too, it seems really nice