Comment by Slim on "AMA: I'm Tomasz Łakomy. Senior Frontend Engineer. Ask me Anything!"

Hi, thanks for doing this AMA and answering our questions. I have some questions:

When you work in big react project using state management libraries like redux or any other one, how you write tests for components? Do you write tests for every component and try to coverge 80 or 90% of the application or you choose the the components that are more complicated and contains a complex logic to test?
What advices can you give to developers in order to write well tests for a big react project in order to deliver a good product?
Do you think that AWS becomes an important thing nowadays and engineers have to know about it and learn it?
What are the tips that you can give for anyone who wants to speak at tech conferences for first time. Are there any things to prepare to be chosen (design a great portfolio, contribution on open source projects, developing consistant applications, etc)? Do you have to choose a new subject that does not exist before to be chosen? Or you have to be a software engineer in a big company or well known on social media (like youtube, twitch, etc ...) to belong the speakers?

Thanks for your time and for your comprehension.

Hey slim, thanks - those are great questions! Let me go through them one by one:

1 - If I had to choose - it's better to write tests for those larger, more complicated components (for instance - containers rendering decent chunk of the application logic). It's more difficult but it'll also give you more confidence that your app works as intended and there are no obvious bugs.

Chasing 100% coverage IMHO is not necessary - not only it'll be a huge effort but also may not provide you with the confidence you'd like if your tests are validating the implementation instead of behaviour.

Not every component needs tests - small components with little-to-no-logic (like wrappers that only render their children wrapper in a div or something) don't really need tests.

In general - focus on testing things that give you the most value.

2 - I actually have a post about this! dev.to/tlakomy/what-i-ve-learned-about-testing-re… In general - focus on testing the behaviour of your app and not its implementation. You should be able to refactor your code without breaking the tests and make sure that the most important flows of your application are well tested.

3 - AWS (and cloud in general) are going to become more and more important for developers but I don't believe that engineers have to learn AWS. My advice is to always keep your eyes open for new technologies but don't learn things just because they're trending - but once you'll have a use case for AWS, then by all means go for it! You can start here: egghead.io/playlists/learn-aws-lambda-from-scratc…

4 - Ha, I also have a whole post about this! dev.to/tlakomy/what-i-wished-someone-told-me-abou…

But I'd like to emphasise one thing that you touched upon.

You ABSOLUTELY DON'T NEED to be a well known developer or work for a large, fancy tech company in order to start speaking at conferences. When I decided that I'd like to speak at conferences outside of my country (Poland), I had like 100 followers on Twitter, nobody knew who I was but I kept grinding.

In 2017 I submitted more CFPs than I can remember but I got a chance to speak at React Day Verona 2017 in Italy and afterwards I got a tremendous opportunity of speaking at many more international conferences which is a fantastic experience, I highly recommend that.

Search Hashnode