So your view is narrowed on your own use cases and from that you conclude that therefore, unit testing front end code was (probably) universally useless?
Unit tests have two main advantages to more involved tests: they are cheap and fast to run and closer to the code they are testing, therefore hopefully eliminating side effects, allowing you to spot issues faster and also to pinpoint their origins more precisely. They are not meant to replace integration or end-to-end tests, but like strict types a barrier for soundness issues, just for other things than types.
That being said, you are right that it's actually useless to test what had already been tested: you don't have to test that e.g. react or angular will render your front end at all or will call your event handlers on the events they were supposed to be bound to. These packages already have extensive test suites to ensure they work.
What you want to unit test is the edge cases in your units, the decisions, the logic flow. It may be small in your front end (it's much more complex in ours, which is a full blown meeting web app and a lot of the business logic runs in the front end), but unit testing it should still be valuable, even if not necessary in every single case.
These packages already have extensive test suites to ensure they work
Great point.
What you want to unit test is the edge cases in your units, the decisions, the logic flow
My point is that if you've got decisions or "logic flow" in your frontend, you're (probably) doing something wrong - Yet again, I write about general cases, not applicable to all cases, something I create an argument towards using Canva as an example.
even if not necessary in every single case
Change "every single case" to "what most developers are doing in most of their cases" and we agree here I think ...
My point is that if you've got decisions or "logic flow" in your frontend, you're (probably) doing something wrong
It really depends on your use case. But even if you don't have to manage WebRTC streams in the front end, having logic there can be advantageous for one of two reasons: being able to use the application while being offline temporarily and being a lot faster during times of slow connections. And that applies to most, if not all cases.
Yes it does, and I accommodate for that, in particular as I mention Canva as one example. However, 98% of the use cases in the enterprise development segment doesn't need it, period!
80% of software developers don't work for software companies, but companies having software development as a secondary function. This can be insurance companies, banks, hospitals, or any other company who's purpose it is to do something else besides delivering software. If you doubt that number, you need to do some research yourself. It's not only a factual statement, it's also an obvious statement ...
And another number that you very probably just thought up. And even if it was correct, after all is said and done, at the end of the day, your software or the software building on it is going to be used by humans. Worsening their user experience merely because you are opinionated against front end business logic is a recipe for bad software.
If you doubt that number, you need to do some research yourself.
you are opinionated against front end business logic is a recipe for bad software
This I actually have scientific numbers on, even thought I can't remember the exact figures. I participated in a trend report for DZone a year ago, and if I don't remember wrong we had 650 participants, having 90% claiming they did not put business logic into the frontend. Which makes sense. Look it up if you wish. It's still out there somewhere ...
As to me "pulling number out of thin air" in regards to how many are working for companies having software development as a secondary function, this is a flawed argument, down the same line as some of your flawed argumentation techniques you yourself attacked in one of your article a couple of weeks ago ...
...we had 650 participants, having 90% claiming they did not put business logic into the frontend.
And this is an example of the argument from majority fallacy. First of all, the front end only became capable of reasonably running business logic within the last ~5-10 years. Second, this is also paired with a fallacy of composition: I could ask the same question at a front end conference and get a completely different result (granted, it wouldn't be representative, either).
this is a flawed argument
If you call something a flawed argument, you are required to show where the flaw is - as I do. The claim that you invented the number also is an assertion and not an argument, so your objection here is flawed and misleading, as it only explained why I was asking for sources.
This calls for an example. The shopping cart is a crucial element in every web shop, driven by business logic. If its logic is solely handled on the server and the user has connection issues, it will simply stop working.
Now, if you extend that logic into the front end, you can ensure that the user still can use your shop without missing a beat and just notify him if some data changed after putting things into the cart once the connection is back to normal.
You're using front end business logic to solve actual user issues in that example. Failing to understand that limits your ability to create excellent software.
If its logic is solely handled on the server and the user has connection issues, it will simply stop working
Yes, but creating "unit tests" for a shopping card implies having to fake a user, with the entire DOM, and the whole shebang, using weird frameworks and tools, allowing you to automatically pretend that some automated process is a user. These aren't unit tests but something completely different.
The purpose of a unit test is the same purpose as the seat belts in a formula 1 car, which is to secure the driver such that he or she can drive faster, without risking their lives as a consequence. Hence, the foundation for unit tests is to (long term) increase velocity of project maintenance, without risking introducing new bugs.
If you start "unit testing" your shopping cart's behaviour, you end up not testing "logic" but rather CSS selectors, DOM manipulations, and GUI. This is first of all extremely difficult to automate, and more importantly results in reducing the velocity which you can maintain the project at, since even a microscopic change in your UI requires you to change and modify the "unit test".
Hence, your "unit test" (bad word for it really) is no longer increasing the velocity at which you can maintain your project but rather decreasing the velocity at which you can maintain your project.
Sometimes it helps to stop and ask yourself "why". If you did that with frontend unit tests, you'd see clearly as the sun that 80% of the time they're pure madness ...
Say, if you're testing on the back end, you don't have an operating system running underneath and libraries to support both your code and your tests and don't mock user behavior (i.e. requests, data, profiles)?
Also, we have 2022, in case you didn't notice. Running automated tests with a virtual DOM is rather simple now. Yes, you can be bad at unit testing front end code, but ignorance about something is not a valid reason that it is inherently bad.
Running "unit tests" relying upon the DOM is like saying "killing for peace". I've explained why in my former comment to you, and I don't like repeating myself, and you did not answer my concerns.
So your view is narrowed on your own use cases and from that you conclude that therefore, unit testing front end code was (probably) universally useless?
Unit tests have two main advantages to more involved tests: they are cheap and fast to run and closer to the code they are testing, therefore hopefully eliminating side effects, allowing you to spot issues faster and also to pinpoint their origins more precisely. They are not meant to replace integration or end-to-end tests, but like strict types a barrier for soundness issues, just for other things than types.
That being said, you are right that it's actually useless to test what had already been tested: you don't have to test that e.g. react or angular will render your front end at all or will call your event handlers on the events they were supposed to be bound to. These packages already have extensive test suites to ensure they work.
What you want to unit test is the edge cases in your units, the decisions, the logic flow. It may be small in your front end (it's much more complex in ours, which is a full blown meeting web app and a lot of the business logic runs in the front end), but unit testing it should still be valuable, even if not necessary in every single case.
Great point.
My point is that if you've got decisions or "logic flow" in your frontend, you're (probably) doing something wrong - Yet again, I write about general cases, not applicable to all cases, something I create an argument towards using Canva as an example.
Change "every single case" to "what most developers are doing in most of their cases" and we agree here I think ...
It really depends on your use case. But even if you don't have to manage WebRTC streams in the front end, having logic there can be advantageous for one of two reasons: being able to use the application while being offline temporarily and being a lot faster during times of slow connections. And that applies to most, if not all cases.
Yes it does, and I accommodate for that, in particular as I mention Canva as one example. However, 98% of the use cases in the enterprise development segment doesn't need it, period!
I'd like to see your sources for that number, because I get the feeling that you just pulled it out of thin air.
80% of software developers don't work for software companies, but companies having software development as a secondary function. This can be insurance companies, banks, hospitals, or any other company who's purpose it is to do something else besides delivering software. If you doubt that number, you need to do some research yourself. It's not only a factual statement, it's also an obvious statement ...
And another number that you very probably just thought up. And even if it was correct, after all is said and done, at the end of the day, your software or the software building on it is going to be used by humans. Worsening their user experience merely because you are opinionated against front end business logic is a recipe for bad software.
So you also never heard about the burden of proof? Figures.
This I actually have scientific numbers on, even thought I can't remember the exact figures. I participated in a trend report for DZone a year ago, and if I don't remember wrong we had 650 participants, having 90% claiming they did not put business logic into the frontend. Which makes sense. Look it up if you wish. It's still out there somewhere ...
As to me "pulling number out of thin air" in regards to how many are working for companies having software development as a secondary function, this is a flawed argument, down the same line as some of your flawed argumentation techniques you yourself attacked in one of your article a couple of weeks ago ...
And this is an example of the argument from majority fallacy. First of all, the front end only became capable of reasonably running business logic within the last ~5-10 years. Second, this is also paired with a fallacy of composition: I could ask the same question at a front end conference and get a completely different result (granted, it wouldn't be representative, either).
If you call something a flawed argument, you are required to show where the flaw is - as I do. The claim that you invented the number also is an assertion and not an argument, so your objection here is flawed and misleading, as it only explained why I was asking for sources.
OK, let me summarise the flaw; "frontend business logic" - It really encapsulates the entirety of the problem ...
This calls for an example. The shopping cart is a crucial element in every web shop, driven by business logic. If its logic is solely handled on the server and the user has connection issues, it will simply stop working.
Now, if you extend that logic into the front end, you can ensure that the user still can use your shop without missing a beat and just notify him if some data changed after putting things into the cart once the connection is back to normal.
You're using front end business logic to solve actual user issues in that example. Failing to understand that limits your ability to create excellent software.
Yes, but creating "unit tests" for a shopping card implies having to fake a user, with the entire DOM, and the whole shebang, using weird frameworks and tools, allowing you to automatically pretend that some automated process is a user. These aren't unit tests but something completely different.
The purpose of a unit test is the same purpose as the seat belts in a formula 1 car, which is to secure the driver such that he or she can drive faster, without risking their lives as a consequence. Hence, the foundation for unit tests is to (long term) increase velocity of project maintenance, without risking introducing new bugs.
If you start "unit testing" your shopping cart's behaviour, you end up not testing "logic" but rather CSS selectors, DOM manipulations, and GUI. This is first of all extremely difficult to automate, and more importantly results in reducing the velocity which you can maintain the project at, since even a microscopic change in your UI requires you to change and modify the "unit test".
Hence, your "unit test" (bad word for it really) is no longer increasing the velocity at which you can maintain your project but rather decreasing the velocity at which you can maintain your project.
Sometimes it helps to stop and ask yourself "why". If you did that with frontend unit tests, you'd see clearly as the sun that 80% of the time they're pure madness ...
Say, if you're testing on the back end, you don't have an operating system running underneath and libraries to support both your code and your tests and don't mock user behavior (i.e. requests, data, profiles)?
Also, we have 2022, in case you didn't notice. Running automated tests with a virtual DOM is rather simple now. Yes, you can be bad at unit testing front end code, but ignorance about something is not a valid reason that it is inherently bad.
Running "unit tests" relying upon the DOM is like saying "killing for peace". I've explained why in my former comment to you, and I don't like repeating myself, and you did not answer my concerns.
Let's agree to disagree. The DOM is merely the operating system of the front end. There's nothing complicated about testing in this environment.