Hacktoberfest is coming up. If you’re new to open source contribution and unsure how to help, may I suggest refactoring code? You can provide a fresh perspective to unclear code and discover ways to leave it better than you found.
There are 3 refactoring techniques that I often practice:
Knowing how to apply just these 3 can get you far. I’ll explain what they mean and how I used them (or should have used them) in projects.
In the last two blog posts, you learned that Ember treats testing as a first-class citizen. Out of the box, Ember provides 3 types of tests so that you can fine-tune test coverage and performance. It also supports a variety of addons and debugging tools to improve your developer experience in testing.
Today, we address an important question: How should you write tests? By the end of this post, you will learn 5 simple rules that I like to follow. The rules aren’t do-this-or-do-that’s (cold hard facts). Instead, they carry nuance and interesting side stories. To keep your learning experience fun, I will transcribe my talk at EmberFest 2019 (rather than summarizing it) to engage in a dialogue with you.
Ember gives you the power to write tests and be productive from day one. You can be confident that your app will be correct today and years from now. A question remains: How should you write tests?
Since tests are a core part of the Ember framework and your development cycle, I will dedicate several blog posts on best practices for writing tests, based on my experience at work and former life as mathematician.
Today, we will cover why testing is important, what tools can help you with testing, and how to run and debug your tests.
Please note that some tools may be readily available for Ember only. However, the best practices that I will mention should be independent of your framework. After all, tests are a universal language, just like math is.