5 ms·

I have yet to see a good frontend test, but I'm waiting to be enlightened. For the most part, it just seems to be things like "if they click this button, make s

I have yet to see a good frontend test, but I'm waiting to be enlightened. For the most part, it just seems to be things like "if they click this button, make sure this div is gone." That smells like a test double to me.

latchkey 3y ago
> I have yet to see a good frontend test You haven't written one yourself? Is your theory that since you can't write one, they aren't possible? All my tests are good enough to ensure that if I upgrade a library or change underlying functionality, something breaks if the output is not expected. That is my primary concern and that is what I test for.
- Capricorn2481 3y ago
  No, that's not what I meant. I mean tests are great on the backend, but I've never seen them prevent a bug on the frontend, especially in react where it's usually obvious what effect your changes will have. In fact, many frontend tests don't even truly test the UI
  - latchkey 3y ago
    https://github.com/lookfirst/mui-rff/blob/master/test/Autocomplete.test.tsx https://github.com/lookfirst/mui-rff/blob/master/test/Autoco...
    - Capricorn2481 3y ago
      > disables input when disabled is passed That's exactly the kind of test double I'm talking about
      - latchkey 3y ago
        And? There was an actual bug filed around that and the issue was resolved with a test that ensures it doesn't happen again. That is all I care about. Make sure we don't make the same mistake twice and that over time things continue to work with new versions.
      - nraf 3y ago
        Can you elaborate on what’s problematic with this test? Testing that the component does what expected based on input is telling me the component is working as expected.
        Scarblac 3y ago
        The developer that forgets to make disable work, will also forget to write this kind of test for it. Once the behaviour is added, it'll never be randomly removed again so the test isn't needed then. It looks nice but never helped find a bug.
        latchkey 3y ago
        Part of the complexity of integrating a form library with a ux library is passing all of the correct properties around between the two. In this case, I wasn't doing that correctly and it resulted in a bug where disabled was not being set correctly. Someone filed a bug. The bug was fixed and a test was written to ensure that this doesn't happen again in the future. You can read the history here: https://github.com/lookfirst/mui-rff/issues/455 https://github.com/lookfirst/mui-rff/issues/455 If you're working with people who randomly 'forget' things while they are doing development, then I guarantee that you're working with people who also write buggy code. In fact, in this case, it was ME who wrote that buggy code. I own it. Not all code gets 100% coverage and sometimes things get missed. That is ok. What is not ok is skipping tests because you might forget something and therefore think it isn't worth writing tests at all. I consider buggy code the act of developers writing the code at least 2x instead of 1x. If you or your company is paying someone $X a year to write code once and they are actually writing code more than once, then I would highly suggest you look for new people to work with because that is a terrible return on investment. If your developers are writing tests, along with their code, then the code is far more likely to be correct and better thought out and less buggy than code that was just hand tested as they developed it. Speaking of that 2x example, I'd rather pay someone 2x the amount of time to write code, with tests, than the other way around.
        Scarblac 3y ago
- Scarblac 3y ago
  I know how to make tests for _logic_, that's usually in Typescript functions (e. g., React hooks). But for components, that call some of those hooks and then render some JSX, I've never been able to write a test that found a bug later on. Every single time one of them failed, either the change made was so large that the whole build failed to compile anyway, or it was because there was new desired behaviour and the test needed changing, not the code. If a type of test doesn't help find bugs, it's a waste of space.
  - latchkey 3y ago
    I've given an example of a whole repository, that is now 4 years old, full of the types of tests you're talking about. It isn't that hard. If the desired behavior is changing, then the test should fail and yes, you need to rewrite it. That's how testing works.
    - Scarblac 3y ago
      It's not hard, but they just make the build of our monorepo take longer and longer without finding actual bugs, in my experience. I feel most unit tests should be commented out once the thing under test is done.
      - latchkey 3y ago
        You are arguing against tests. It is not a winnable argument.
        Capricorn2481 3y ago
        No, people are arguing against frontend tests because they're orthogonal to test driven development
        latchkey 3y ago
        I really don't understand this comment at all.
LocalPCGuy 3y ago
We have hundreds of tests for our client side projects (web app, mobile app), and they definitely do more than what you describe. Some are simple (although very few are as simple as your example) and some are complex, depending on the portion of the app being tested. Some are basically integration tests for components/widgets, where it runs it in isolation to test the inputs and outputs. Others are more like traditional unit tests where it's purely testing business logic, API and model interactions (mocked), form validation logic, etc. Unless you're talking about very simple client apps, there's always stuff that can be tested that will provide significant business value by preventing bugs and broken code from getting to end users
- a_wild_dandan 3y ago
  Could you give an example? Most UI tests I see are either a) trivial/tautological, b) test implementation details, or c) doesn’t actually even test the UI, i.e “what is visually painted on-screen.”
  - latchkey 3y ago
    https://github.com/lookfirst/mui-rff/blob/master/test/Autocomplete.test.tsx https://github.com/lookfirst/mui-rff/blob/master/test/Autoco...
  - gary_bernhardt 3y ago
    Almost none of the e2e tests for https://www.executeprogram.com https://www.executeprogram.com meet this description. They're all tests like: - Visit a lesson page with a code example that returns a string. - Enter the correct answer to that code example, but without the quotes around it. - Assert that the text "Almost, but the answer is a string so it needs quotes." now exists on the page. No implementation knowledge, nothing faked, real UI behavior tested. You can test most app behavior like this. E.g, we test our entire billing system like this, making these kinds of real assertions. (To make sure that we know when actual rendered pixels change unexpectedly, we use Percy, which is a separate topic.)
  - pixelrevision 3y ago
nazka 3y ago
You should take a look at the end to end testing tool named Cypress. As an end to end test it goes beyond click this check that. As an end to end test it will make sure that your app with its features works seamlessly for the user and that your React components work well together. Cypress is amazingly built and it is super fast to write tests with it. It’s easier to debug and seeing the robot doing the tests is pretty cool. For me it’s a must have. You can check: https://youtu.be/BQqzfHQkREo https://youtu.be/BQqzfHQkREo https://youtu.be/OVNjsIto9xM&t=28m06s https://youtu.be/OVNjsIto9xM&t=28m06s https://youtu.be/VvLocgtCQnY https://youtu.be/VvLocgtCQnY
- latchkey 3y ago
  Right, that is the one I was thinking about. Thanks!

latchkey 3y ago

> I have yet to see a good frontend test You haven't written one yourself? Is your theory that since you can't write one, they aren't possible? All my tests are good enough to ensure that if I upgrade a library or change underlying functionality, something breaks if the output is not expected. That is my primary concern and that is what I test for.

Capricorn2481 3y ago
No, that's not what I meant. I mean tests are great on the backend, but I've never seen them prevent a bug on the frontend, especially in react where it's usually obvious what effect your changes will have. In fact, many frontend tests don't even truly test the UI
- latchkey 3y ago
  https://github.com/lookfirst/mui-rff/blob/master/test/Autocomplete.test.tsx https://github.com/lookfirst/mui-rff/blob/master/test/Autoco...
  - Capricorn2481 3y ago
    > disables input when disabled is passed That's exactly the kind of test double I'm talking about
    - latchkey 3y ago
      And? There was an actual bug filed around that and the issue was resolved with a test that ensures it doesn't happen again. That is all I care about. Make sure we don't make the same mistake twice and that over time things continue to work with new versions.
    - nraf 3y ago
      Can you elaborate on what’s problematic with this test? Testing that the component does what expected based on input is telling me the component is working as expected.
      - Scarblac 3y ago
        The developer that forgets to make disable work, will also forget to write this kind of test for it. Once the behaviour is added, it'll never be randomly removed again so the test isn't needed then. It looks nice but never helped find a bug.
        latchkey 3y ago
        Part of the complexity of integrating a form library with a ux library is passing all of the correct properties around between the two. In this case, I wasn't doing that correctly and it resulted in a bug where disabled was not being set correctly. Someone filed a bug. The bug was fixed and a test was written to ensure that this doesn't happen again in the future. You can read the history here: https://github.com/lookfirst/mui-rff/issues/455 https://github.com/lookfirst/mui-rff/issues/455 If you're working with people who randomly 'forget' things while they are doing development, then I guarantee that you're working with people who also write buggy code. In fact, in this case, it was ME who wrote that buggy code. I own it. Not all code gets 100% coverage and sometimes things get missed. That is ok. What is not ok is skipping tests because you might forget something and therefore think it isn't worth writing tests at all. I consider buggy code the act of developers writing the code at least 2x instead of 1x. If you or your company is paying someone $X a year to write code once and they are actually writing code more than once, then I would highly suggest you look for new people to work with because that is a terrible return on investment. If your developers are writing tests, along with their code, then the code is far more likely to be correct and better thought out and less buggy than code that was just hand tested as they developed it. Speaking of that 2x example, I'd rather pay someone 2x the amount of time to write code, with tests, than the other way around.
        Scarblac 3y ago
Scarblac 3y ago
I know how to make tests for _logic_, that's usually in Typescript functions (e. g., React hooks). But for components, that call some of those hooks and then render some JSX, I've never been able to write a test that found a bug later on. Every single time one of them failed, either the change made was so large that the whole build failed to compile anyway, or it was because there was new desired behaviour and the test needed changing, not the code. If a type of test doesn't help find bugs, it's a waste of space.
- latchkey 3y ago
  I've given an example of a whole repository, that is now 4 years old, full of the types of tests you're talking about. It isn't that hard. If the desired behavior is changing, then the test should fail and yes, you need to rewrite it. That's how testing works.
  - Scarblac 3y ago
    It's not hard, but they just make the build of our monorepo take longer and longer without finding actual bugs, in my experience. I feel most unit tests should be commented out once the thing under test is done.
    - latchkey 3y ago
      You are arguing against tests. It is not a winnable argument.
      - Capricorn2481 3y ago
        No, people are arguing against frontend tests because they're orthogonal to test driven development
        latchkey 3y ago
        I really don't understand this comment at all.

LocalPCGuy 3y ago

We have hundreds of tests for our client side projects (web app, mobile app), and they definitely do more than what you describe. Some are simple (although very few are as simple as your example) and some are complex, depending on the portion of the app being tested. Some are basically integration tests for components/widgets, where it runs it in isolation to test the inputs and outputs. Others are more like traditional unit tests where it's purely testing business logic, API and model interactions (mocked), form validation logic, etc. Unless you're talking about very simple client apps, there's always stuff that can be tested that will provide significant business value by preventing bugs and broken code from getting to end users

a_wild_dandan 3y ago
Could you give an example? Most UI tests I see are either a) trivial/tautological, b) test implementation details, or c) doesn’t actually even test the UI, i.e “what is visually painted on-screen.”
- latchkey 3y ago
  https://github.com/lookfirst/mui-rff/blob/master/test/Autocomplete.test.tsx https://github.com/lookfirst/mui-rff/blob/master/test/Autoco...
- gary_bernhardt 3y ago
  Almost none of the e2e tests for https://www.executeprogram.com https://www.executeprogram.com meet this description. They're all tests like: - Visit a lesson page with a code example that returns a string. - Enter the correct answer to that code example, but without the quotes around it. - Assert that the text "Almost, but the answer is a string so it needs quotes." now exists on the page. No implementation knowledge, nothing faked, real UI behavior tested. You can test most app behavior like this. E.g, we test our entire billing system like this, making these kinds of real assertions. (To make sure that we know when actual rendered pixels change unexpectedly, we use Percy, which is a separate topic.)
- pixelrevision 3y ago

nazka 3y ago

You should take a look at the end to end testing tool named Cypress. As an end to end test it goes beyond click this check that. As an end to end test it will make sure that your app with its features works seamlessly for the user and that your React components work well together. Cypress is amazingly built and it is super fast to write tests with it. It’s easier to debug and seeing the robot doing the tests is pretty cool. For me it’s a must have. You can check: https://youtu.be/BQqzfHQkREo https://youtu.be/BQqzfHQkREo https://youtu.be/OVNjsIto9xM&t=28m06s https://youtu.be/OVNjsIto9xM&t=28m06s https://youtu.be/VvLocgtCQnY https://youtu.be/VvLocgtCQnY

latchkey 3y ago
Right, that is the one I was thinking about. Thanks!