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.
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.