Closed SalihuDickson closed 5 months ago
JaeAeich
commented
1 year ago @SalihuDickson can you maybe link to where these guidelines are, would love to read and contribute. Just want my further commits to comply to the standards :slightly_smiling_face:
SalihuDickson
commented
1 year ago oh sure @JaeAeich, I probably should have done that earlier. Keep in mind that this is still really incomplete as I am just now testing out the practicality of some of these guidelines and I am still figuring out a lot of stuff that I haven't documented.
Description
This is a proposal to create a testing guide for the components in this repo. In the future we hope to expand this project and have other developers contribute to current projects by updating dependencies, fixing bugs, implementing new features or refactoring outdated code and more. And to achieve low friction environment during collaboration we will need to implement many tests to make sure future and current developers can easily spot breaking changes and know exactly where the issues are coming from. We need to build a testing guide to make sure all our components are built with a high level of testing and to have these tests implemented in standardized way so that they are easy to work with
Possible solution(s)
Outline of the proposed testing guide:
Introduction: This section will explain the purpose and importance of a testing guide, and emphasize the benefits of comprehensive testing for web components.
Testing strategy: This section will discuss the overall testing strategy for our web components, explain the different types of tests (e.g., unit tests, integration tests, end-to-end tests) and their purposes, and define the scope and responsibilities of different types of tests in the repository.
Testing Tools and libraries: This section will List the testing tools and libraries used in the repository, provide instructions for setting up and configuring the testing environment, and maybe explain the purpose and benefits of each tool or library.
Unit testing: This section will explain the importance of unit testing for web components, discuss the characteristics of good unit tests, provide guidelines for writing unit tests for components, and discuss mocking and stubbing techniques when necessary.
Integration testing: This section will discuss the importance of integration testing for web components, provide guidelines for writing integration tests for components, explain how to test component interactions and dependencies and discuss the use of testing frameworks or libraries specific to web components.
End-to-end testing: This section will discuss the purpose and benefits of end-to-end (E2E) testing for web components, provide guidelines for writing E2E tests to cover user interactions and workflows, and discuss tools and frameworks suitable for E2E testing in the repository.
Best practices and tips: This section will provide general best practices for writing effective tests, discuss guidelines for test organization, naming conventions, and readability, promote the use of test-driven development (TDD) or similar methodologies, and share tips for writing reliable and resilient tests for web components. This will mostly be references to established standards.
Additional Testing and Considerations: This section will discuss possible special considerations for testing custom web components, that don't really fit in any other section, and that can trip developers up while writtng tests, such as Shadow DOM or lifecycle methods.This section will also Discuss accessibility testing for web components (we might need to give this it's own section).This section may also eventually address performance testing or benchmarking for components, if applicable, if and when we get into more complex component testing.
Conclusion: This section can, among other things, summarize the key points covered in the testing guide, encourage developers to prioritize testing and follow the guidelines provided, and further express our commitment to quality and maintainable web components through comprehensive testing, as well as give some disclaimers.
We don't need to come up with an entire testing guide ourselves, Ideally the best solution will have information and references to already established standards, although we need something specific to the packages we are building and not a generic guide that will be difficult to completely follow.