[Question] Sharing context between specs: good or bad?
See original GitHub issueI chatted with @dgozman about this a bit here. https://github.com/playwright-community/jest-playwright/pull/96#issuecomment-608587152
I understand that in theory it makes sense to not share context, but the end result I’m seeing doesn’t seem ideal.
When I share context:
describe('editor/page', () => {
it('can log in and create a site', async () => {});
it('can create a page and add content', async () => {});
it('can publish the site', async () => {});
it('can delete the page', async () => {});
});
When I don’t share context:
describe('editor/page', () => {
it('can create a site, add a page, add content, publish, and delete the page', async () => {
// Create a site
[some code here]
// Create a page
[some code here]
// Add content
[some code here]
// Publish
[some code here]
// Delete the page
[some code here]
});
});
I find the code a bit easier to read in the first example, and the output in Jest looks a bit nicer too. Do you have any thoughts about how to achieve clearer code and output without sharing context?
Thanks!
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:7 (7 by maintainers)
Top Results From Across the Web
Better Specs. Testing Guidelines for Developers.
Contexts are a powerful method to make your tests clear and well organized (they keep tests easy to read). When describing a context,...
Read more >Nested Context Blocks in RSpec - ruby - Stack Overflow
I strongly recommend that you check out Better Specs to know more about the best practices while using contexts in your RSpec tests....
Read more >Risks and challenges of data access and sharing
As shown at the Copenhagen Expert Workshop, data access and sharing are about taking data from one context and transferring it to another...
Read more >Set up Preconditions: Background, Scenario Outline, or Hooks
Second, it introduces an implied dependency on the sequence of execution between feature tests, which is bad for all the same reasons as...
Read more >Testing best practices - GitLab Docs
GitLab development guidelines - testing best practices. ... While most Ruby instances are not shared between specs, classes and modules generally are.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I still haven’t come up with a great answer for this. For now what I’m doing is this:
I don’t love this because I end up with very long test names in order to include everything that’s happening in the test, and the test output doesn’t contain any grouping of related actions. That being said though, I don’t have a better idea for how to fix this at the moment. I think some type of test group support would be great for this, but that’s a lot of work and I’m not sure this is an area of focus for you.
Up to you whether you’d like to keep this open based on if this is an area of interest to the team. Thanks for checking in!
Fair point @dgozman. I think the name isn’t a huge issue. But some kind of step delineator would be really nice.