A screenshot of a very specific component is a styling unit test. Search for "CSS unit testing" on Google.
"None of what you said is unit testing, apart of the things that are unit testing" xD
I get the "business code in the frontend" thing, but the same way in the backend you have things and interfaces to those things and you test everything as "testing backend code is good", a frontend is just an interface for a backend that also should be tested as it may have been implemented incorrectly, for example. More than "frontend and backend" is a "server and client", and a client needs to be tested. The thing with frontends is that they are stylish and visually cool clients.
I hope that you don't dare to create a pure backend client to another service (socket, rest, whatever) and you don't test it.
OK, so if I changes the colour of my button my unit test fails? How is that productive really? I answered another guy here that the purpose of unit tests is to increase long term project velocity. Having unit tests that needs to be updated every single time I apply a UI change, is like having a formula 1 car with a permanently opened parachute hanging behind it.
Unit tests shouldn't even touch networking my friend. Add "screen shots" to it, and I have no word for what it is, but it certainly isn't "unit testing" ...
If changing a button colour intentionally breaks your tests, that means that you don't know how to create proper CSS unit tests. You can't complain about something that you have never used, so you are just failing with noob guessings and thinking that something is bad because you have not experience with it, at least enough experience.
For example, in a UI you always have predefined colours. You never have a single button with a forced specific colour if it doesn't come from a "master list". SCSS comes really handy for this (although there are also CSS variables).
If you change a button colour, you actually modify that master list. Is a good practice to have it. The objective is to be able to modify almost the entire styling by just modifying those variables instead of fiddling inside the CSS code. All those variables are the ones you will be able to test properly, so you can forget about them in the "manual" testing (yay). The more you add, the better (roundness of a button? padding between elements? Element display depending on a condition? I don't know, whatever thing you could think of).
Then, you can match the UI colours to that master list. If you want to change a button colour, you change the corresponding colour on that master list, so your tests will drink from that table.
If you add another class to a button, or to a button parent, or modify the box-sizing by mistake, styling tests will fail, because the tests expected that button to have a CSS output that you previously saved in your first manual test.
It follows the basic principles:
Tests are automatic.
Tests can be unitary.
You don't have to modify tests for them to inherit changes on purpose.
Obviously if you modify the master list by mistake, is going to be more difficult to detect, but being a master list is not a bug if you modify the main selection color to "red" instead of "blue" as the owner asked, as the main purpose of the master list is to reflect to the UI the values that you selected. You may have a "master list validator" which checks that the master list contains the company colours, but well... this is a bit weird xD
The good thing is that is saves you from small mistakes that could happen from modifying the styling or HTML, specially those that move a single pixel, modify a button hover, or modify a 1px border, which are more difficult to detect. In reality, you are testing that the CSS that you want to apply is the one actually applying, even on different screen sizes, and it helps.
Is more difficult to do CSS testing than code testing, but is testable to a level where you can start to discard manual tests, which is the main point of all this.
The first time I did GUI testing was in 2001 my friend. It was for a GUI library called SmartWin. Since then I’ve used Selenium, and all sorts of tech in this space. All have one thing in common, the reduce project maintenance velocity, without providing the required security net. But, it’s quite irrelevant. The thing you’re describing as unit tests have never been unit tests, and will never become it either. Regardless of terms, it’s still like having a constantly mounted parachute hanging out from behind a Formula 1 car, and hence by the very definition of the term contra productive, providing the exact opposite result of the intentions behind unit tests …
I've known developers for 20 years that still have duplicate code in their projects. Doing something a lot or since my grandad was a teen doesn't mean that you are doing it properly. Specially when you say that you had problems with that since then and didn't ever fixed them in any way.
I know how I do my front end testing, and the day I got used to it and thought deeply what I wanted to achieve, I had any of those problems, because we are lucky that in our world, almost any programming problem can be fixed with enough focus. My front end tests are not counter productive, but whatever. I don't have 100% coverage, but great part of the manual labor is now gone, without any development complication.
Is like saying that OOP or functional or so and so paradigm is bad because I'm having problems, which are actually not good coding skills on that, because of lack of experience or lack of interest on improving.
Your post is a big red flag actually, so whatever.
Doing something a lot or since my grandad was a teen doesn't mean that you are doing it properly
That statement has literally been scientifically disproven by research. I could point you the way, but it's too late, so I'll just give you a hint; 10,000 hours ...
Specially when you say that you had problems with that since then and didn't ever fixed them in any way
It's not "me who has a problem with this" it is literally everybody who has a problem with it - Some of us just (still) live in denial ... :/
can be fixed with enough focus
Everything that requires "enough focus" is fundamentally broken. If your code, framework, language, or library of choice forces me to think, it is fundamentally broken!
I didn't say that you write duplicated code. What I'm saying is that after 20 years since your first GUI test, you are still failing in a very obvious way. I think that you are talented in other programming fields, but in the frontend... I have my opinion here.
Internet is also full of big red flag posts about OOP or about functional programming, because "everybody has problems with it", but they are just bad quality code that leads to problems. And this applies perfectly here. In Spain there's a saying: "problem of many, fool's consolation".
With "enough focus" I mean to not live in denial saying "this is shit, and specially because other programmers also have the same problem", but instead to actually think what you want to achieve and how. Is not a code, framework, language or library. Is a FIXABLE PROBLEM that you are leveraging to a MANUAL TEST or even worse: NOT TESTING it at all. It says a lot about your code quality ethics. Looking at your website aista.com, you receive slaps on the first double-load, so...
Keep on writting big read flag posts while having a buggy website. I'm out here (muting the thread) and your obvious fool's consolation. Not going to waste more time.
Bye.
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.
A screenshot of a very specific component is a styling unit test. Search for "CSS unit testing" on Google.
"None of what you said is unit testing, apart of the things that are unit testing" xD
I get the "business code in the frontend" thing, but the same way in the backend you have things and interfaces to those things and you test everything as "testing backend code is good", a frontend is just an interface for a backend that also should be tested as it may have been implemented incorrectly, for example. More than "frontend and backend" is a "server and client", and a client needs to be tested. The thing with frontends is that they are stylish and visually cool clients.
I hope that you don't dare to create a pure backend client to another service (socket, rest, whatever) and you don't test it.
OK, so if I changes the colour of my button my unit test fails? How is that productive really? I answered another guy here that the purpose of unit tests is to increase long term project velocity. Having unit tests that needs to be updated every single time I apply a UI change, is like having a formula 1 car with a permanently opened parachute hanging behind it.
Unit tests shouldn't even touch networking my friend. Add "screen shots" to it, and I have no word for what it is, but it certainly isn't "unit testing" ...
If changing a button colour intentionally breaks your tests, that means that you don't know how to create proper CSS unit tests. You can't complain about something that you have never used, so you are just failing with noob guessings and thinking that something is bad because you have not experience with it, at least enough experience.
For example, in a UI you always have predefined colours. You never have a single button with a forced specific colour if it doesn't come from a "master list". SCSS comes really handy for this (although there are also CSS variables).
If you change a button colour, you actually modify that master list. Is a good practice to have it. The objective is to be able to modify almost the entire styling by just modifying those variables instead of fiddling inside the CSS code. All those variables are the ones you will be able to test properly, so you can forget about them in the "manual" testing (yay). The more you add, the better (roundness of a button? padding between elements? Element display depending on a condition? I don't know, whatever thing you could think of).
Then, you can match the UI colours to that master list. If you want to change a button colour, you change the corresponding colour on that master list, so your tests will drink from that table.
If you add another class to a button, or to a button parent, or modify the box-sizing by mistake, styling tests will fail, because the tests expected that button to have a CSS output that you previously saved in your first manual test.
It follows the basic principles:
Obviously if you modify the master list by mistake, is going to be more difficult to detect, but being a master list is not a bug if you modify the main selection color to "red" instead of "blue" as the owner asked, as the main purpose of the master list is to reflect to the UI the values that you selected. You may have a "master list validator" which checks that the master list contains the company colours, but well... this is a bit weird xD
The good thing is that is saves you from small mistakes that could happen from modifying the styling or HTML, specially those that move a single pixel, modify a button hover, or modify a 1px border, which are more difficult to detect. In reality, you are testing that the CSS that you want to apply is the one actually applying, even on different screen sizes, and it helps.
Is more difficult to do CSS testing than code testing, but is testable to a level where you can start to discard manual tests, which is the main point of all this.
The first time I did GUI testing was in 2001 my friend. It was for a GUI library called SmartWin. Since then I’ve used Selenium, and all sorts of tech in this space. All have one thing in common, the reduce project maintenance velocity, without providing the required security net. But, it’s quite irrelevant. The thing you’re describing as unit tests have never been unit tests, and will never become it either. Regardless of terms, it’s still like having a constantly mounted parachute hanging out from behind a Formula 1 car, and hence by the very definition of the term contra productive, providing the exact opposite result of the intentions behind unit tests …
I've known developers for 20 years that still have duplicate code in their projects. Doing something a lot or since my grandad was a teen doesn't mean that you are doing it properly. Specially when you say that you had problems with that since then and didn't ever fixed them in any way.
I know how I do my front end testing, and the day I got used to it and thought deeply what I wanted to achieve, I had any of those problems, because we are lucky that in our world, almost any programming problem can be fixed with enough focus. My front end tests are not counter productive, but whatever. I don't have 100% coverage, but great part of the manual labor is now gone, without any development complication.
Is like saying that OOP or functional or so and so paradigm is bad because I'm having problems, which are actually not good coding skills on that, because of lack of experience or lack of interest on improving.
Your post is a big red flag actually, so whatever.
FYI, I literally wrote the manual on DRY
That statement has literally been scientifically disproven by research. I could point you the way, but it's too late, so I'll just give you a hint; 10,000 hours ...
It's not "me who has a problem with this" it is literally everybody who has a problem with it - Some of us just (still) live in denial ... :/
Everything that requires "enough focus" is fundamentally broken. If your code, framework, language, or library of choice forces me to think, it is fundamentally broken!
I didn't say that you write duplicated code. What I'm saying is that after 20 years since your first GUI test, you are still failing in a very obvious way. I think that you are talented in other programming fields, but in the frontend... I have my opinion here.
Internet is also full of big red flag posts about OOP or about functional programming, because "everybody has problems with it", but they are just bad quality code that leads to problems. And this applies perfectly here. In Spain there's a saying: "problem of many, fool's consolation".
With "enough focus" I mean to not live in denial saying "this is shit, and specially because other programmers also have the same problem", but instead to actually think what you want to achieve and how. Is not a code, framework, language or library. Is a FIXABLE PROBLEM that you are leveraging to a MANUAL TEST or even worse: NOT TESTING it at all. It says a lot about your code quality ethics. Looking at your website aista.com, you receive slaps on the first double-load, so...
Keep on writting big read flag posts while having a buggy website. I'm out here (muting the thread) and your obvious fool's consolation. Not going to waste more time.
Bye.