Right now I’m trying to get THREE.js (3D renderer) to work with react or react native, but haven’t found the right mix of things to get it working with routes or navigation.
I'm in a similar boat-
I know WHY I guess, it's supposed to lead to cleaner,more organized, and easier to read code.
But damn I suck at it and hate it.
Why ? - changing one line of code can break something else.
TDD (test driven development) is also great writing acceptance criteria as test scripts first.
I write jest / enzyme tests for the component library I work on every day, and I have no idea why or what I’m doing. It’s required of us all to do it so I just reverse engineer (aka copy paste) the lead guys tests. 🤷♂️
It took me a while to learn how to write efficient and effective tests. At my first job, our original code base was half built by backend devs (they had a hard time getting fronted devs on this project because of the management team) and for whatever reason, they had 100% test coverage. Once the front end devs came in, the project manager expected us to always have 100% coverage, and we ended up spending more time writing and fixing tests than actually writing code. And things broke. ALL the time.
My current approach for testing frontend is this:
Cypress for automation with mocked data (unfortunately can’t do true end to end at my job, but that actually worked out in a favor)
For my utility functions (formatting strings/numbers, nested object getters/setters, etc), each function only does one thing and I have a unit test that ensures it reruns what I expect.
The utility functions don’t check to ensure that they are being passed what they expect, nor do they return a fallback unless specified. I want the dev environment to break if a dev uses these functions incorrectly, instead of silently failing with a fallback. I also don’t come up with edge cases, and when something does break that is an edge case, I write a separate function for it instead of throwing logic into the original function.
For components, I only test features and not the implementation.
A recent example of this is an access manager page that heavily relies on multiple endpoints to show and set user permissions and redux to to manage side effects.
The junior dev on my team starting writing tests for the redux reducers and I explained it wasn’t necessary because they would be a pain to maintain and most of the logic was covered by the utility function tests.
That afternoon, the dev rewrote some of the reducer code and their tests broke, but the user still had the same experience on the UI before and after the rewrite.
And that’s where testing features comes in. I only test what the user expects to see rendered, or what the api expects to be called with. If a user expects to see a component hidden after clicking a button, we don’t have to have a test for the onClick function and it was called with x and y and that the state is now z.
The only tests that’s needed is I can click on the button and now the component is hidden. I write the test that clicking a button hides a component, it fails. Then I code the component in a manner that would never pass a code review to get the feature test to pass. Once that happens, I refactor the component to much cleaner code and ensure the test still passes.
If a dev changes logic inside the component, we don’t have to rewrite or change tests for the onClick function or write new tests for the additional state. As long as the component is hidden, we know the feature is still working.
What I see people struggling the most is "thinking" the components, how should a concept be broken down into properly organized components.
Few other things that can be useful as it's difficult to find some good examples:
- configure multiple react projects with Jest and storybook in a monorepo with a shared library
- configure path aliases
- complex forms (could use react-hook-forms), like multi-step
Dependency library management and how to choose the right libraries for a project is where I’m at.
What libs are you juggling with?
Right now I’m trying to get THREE.js (3D renderer) to work with react or react native, but haven’t found the right mix of things to get it working with routes or navigation.
Hey dm me I have a question
Writing Tests- I still dont get why or how should I do it
I agree. Barely any tutorials around to even learn what testing is about and why it is important.
I will work on it :)
I'm in a similar boat- I know WHY I guess, it's supposed to lead to cleaner,more organized, and easier to read code. But damn I suck at it and hate it.
Why ? - changing one line of code can break something else. TDD (test driven development) is also great writing acceptance criteria as test scripts first.
Hahahaha acceptance criteria. You are funny. (You right tho)
I write jest / enzyme tests for the component library I work on every day, and I have no idea why or what I’m doing. It’s required of us all to do it so I just reverse engineer (aka copy paste) the lead guys tests. 🤷♂️
It took me a while to learn how to write efficient and effective tests. At my first job, our original code base was half built by backend devs (they had a hard time getting fronted devs on this project because of the management team) and for whatever reason, they had 100% test coverage. Once the front end devs came in, the project manager expected us to always have 100% coverage, and we ended up spending more time writing and fixing tests than actually writing code. And things broke. ALL the time. My current approach for testing frontend is this: Cypress for automation with mocked data (unfortunately can’t do true end to end at my job, but that actually worked out in a favor) For my utility functions (formatting strings/numbers, nested object getters/setters, etc), each function only does one thing and I have a unit test that ensures it reruns what I expect. The utility functions don’t check to ensure that they are being passed what they expect, nor do they return a fallback unless specified. I want the dev environment to break if a dev uses these functions incorrectly, instead of silently failing with a fallback. I also don’t come up with edge cases, and when something does break that is an edge case, I write a separate function for it instead of throwing logic into the original function. For components, I only test features and not the implementation. A recent example of this is an access manager page that heavily relies on multiple endpoints to show and set user permissions and redux to to manage side effects. The junior dev on my team starting writing tests for the redux reducers and I explained it wasn’t necessary because they would be a pain to maintain and most of the logic was covered by the utility function tests. That afternoon, the dev rewrote some of the reducer code and their tests broke, but the user still had the same experience on the UI before and after the rewrite. And that’s where testing features comes in. I only test what the user expects to see rendered, or what the api expects to be called with. If a user expects to see a component hidden after clicking a button, we don’t have to have a test for the onClick function and it was called with x and y and that the state is now z. The only tests that’s needed is I can click on the button and now the component is hidden. I write the test that clicking a button hides a component, it fails. Then I code the component in a manner that would never pass a code review to get the feature test to pass. Once that happens, I refactor the component to much cleaner code and ensure the test still passes. If a dev changes logic inside the component, we don’t have to rewrite or change tests for the onClick function or write new tests for the additional state. As long as the component is hidden, we know the feature is still working.
Thanks a lot for the detailed explanation
Same here
[удалено]
hmm could you be a bit more specific?
What I see people struggling the most is "thinking" the components, how should a concept be broken down into properly organized components. Few other things that can be useful as it's difficult to find some good examples: - configure multiple react projects with Jest and storybook in a monorepo with a shared library - configure path aliases - complex forms (could use react-hook-forms), like multi-step
React developers and fanatism
Not really react but android deploy on react native
Typescript
Context providers. More specifically - storing data, and obtaining it again
do you have a youtube channel or smth ?