3 ms·

I agree with the blog. From my experience that there are a lot of newer inexperienced devs that think that feature tests as unit tests are something valid. (It'

by monksy 8y ago

I agree with the blog. From my experience that there are a lot of newer inexperienced devs that think that feature tests as unit tests are something valid. (It's not and its flat out wrong, and it is dangerous)

azemetre 8y ago
Can you expand upon this? I do a lot of frontend work, and I am slowly getting into the mindset that nearly all testing we do in react using enzyme is worthless compared to doing e2e tests with something like cypress. I rather not have people on my team waste hours writing tests that break the moment props change, or styling changes, or a child component renders breaking the test because they used mount instead of shallow. IDK, I think I just hate Enzyme mostly...
- monksy 8y ago
  In frontend work, you're a little bit of a disadvantage due to the language and what you're testing. If you're testing interface code (something that draws something on the screen) the only way you can test that is if you have a really good testing library that will test it in a virtual drawing space or function/feature tests. With the backend you should have 90% unit tests (1000s of them) all completing in less than 3 minutes, integration tests (7% of all your tests) competing in under say 10 minutes, and feature tests (those shouldn't be in the build but in a post build step that can reject a change)
  - avinium 8y ago
    I disagree - your “90%/7%/3%” seems completely arbitrary. It might be appropriate for some projects but I think it’s wrong to adopt as a hard and fast rule. IMO, the correct amount of testing is the amount that lets you refactor quickly and with confidence that you haven’t broken anything, and that tests pathways/edge cases in complicated logic.
segmondy 8y ago
Feature tests > Unit tests. They are both important, but I rather 100% feature tests and 0 unit tests, than 100% unit tests and no feature tests. If you have passing feature tests, the software sort of works. If you have 100% passing unit tests with 0 functional tests, the software might not even work at all.
- monksy 8y ago
  > sort of works Nope. The only thing it does is pass the test under the conditions that you made the test. There is no validation of the code within the project for correctness, safeness [is validation working or not], or even operation. When you only have feature tests, you have a lot of code that you're not sure that works or not.

by monksy 8y ago

azemetre 8y ago

Can you expand upon this? I do a lot of frontend work, and I am slowly getting into the mindset that nearly all testing we do in react using enzyme is worthless compared to doing e2e tests with something like cypress. I rather not have people on my team waste hours writing tests that break the moment props change, or styling changes, or a child component renders breaking the test because they used mount instead of shallow. IDK, I think I just hate Enzyme mostly...

monksy 8y ago
In frontend work, you're a little bit of a disadvantage due to the language and what you're testing. If you're testing interface code (something that draws something on the screen) the only way you can test that is if you have a really good testing library that will test it in a virtual drawing space or function/feature tests. With the backend you should have 90% unit tests (1000s of them) all completing in less than 3 minutes, integration tests (7% of all your tests) competing in under say 10 minutes, and feature tests (those shouldn't be in the build but in a post build step that can reject a change)
- avinium 8y ago
  I disagree - your “90%/7%/3%” seems completely arbitrary. It might be appropriate for some projects but I think it’s wrong to adopt as a hard and fast rule. IMO, the correct amount of testing is the amount that lets you refactor quickly and with confidence that you haven’t broken anything, and that tests pathways/edge cases in complicated logic.

segmondy 8y ago

Feature tests > Unit tests. They are both important, but I rather 100% feature tests and 0 unit tests, than 100% unit tests and no feature tests. If you have passing feature tests, the software sort of works. If you have 100% passing unit tests with 0 functional tests, the software might not even work at all.

monksy 8y ago
> sort of works Nope. The only thing it does is pass the test under the conditions that you made the test. There is no validation of the code within the project for correctness, safeness [is validation working or not], or even operation. When you only have feature tests, you have a lot of code that you're not sure that works or not.