eschutho opened a new issue #17359: URL: https://github.com/apache/superset/issues/17359
This is a proposal to edit the frontend testing guidelines from: ``` Avoid nesting when you're testing Avoid the use of describe blocks in favor of inlined tests. If your tests start to grow and you feel the need to group tests, prefer to break them into multiple test files. Check this [awesome article](https://kentcdodds.com/blog/avoid-nesting-when-youre-testing) written by Kent C. Dodds about this topic. ``` to Avoid unnecessary abstractions Even though there may be a lot of duplication in tests because you are performing the same actions many times, avoid too many abstractions and drying up code if it means that the tests become unreadable. If almost each line in your test is calling a function defined in a beforeEach block for example, consider its readability and bringing that code back into the test, especially if it's a short block of code that is repeated. I feel that the sentiment of KCD's article is to avoid too much abstraction that would make tests difficult to read. There are still benefits to nesting in describe for the purpose of keeping scenarios together, especially since jest strings together describe tags. i.e., ``` describe('myComponent', () => { describe('when user is logged in', () => { describe('and they do not have a photo', () => { it('should do something') }); describe('when the user is not logged in', () => { it('should do something') }); }); describe('when the user is not logged in', () => { it('should do something') }); }); ``` This writes out the test case like: 'myComponent when user is logged in and they do not have a photo' so it's very convenient to make sure that you're covering a binary set of cases and still have a readable output. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
