Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rearchitect test framework #21

Open
mattmcneeney opened this issue Jan 5, 2018 · 8 comments
Open

Rearchitect test framework #21

mattmcneeney opened this issue Jan 5, 2018 · 8 comments

Comments

@mattmcneeney
Copy link
Contributor

As things stand, the entire suite of tests will have to be duplicated for each minor version (2.13, 2.14, 2.15, etc). However, as these minor versions must be backwards compatible, new minor versions should just mean adding new tests to the suite.

When v3 eventually lands, we'd likely need a brand new suite of tests (similar to how things work today for adding minor versions).

Is anyone up for having a go at this?

@jeremyrickard
Copy link

@mattmcneeney I'd be interested in having a go at this.

@mattmcneeney
Copy link
Contributor Author

Awesome, thanks @jeremyrickard.

@n3wscott @Haishi2016 @arschles Any thoughts on this proposal before this gets underway?

@n3wscott
Copy link
Contributor

👍 do it! maybe the test can know how it matches using semver and path matching? like 2.* and 2.13+ and *, etc...

@arschles
Copy link
Contributor

I'm good with this proposal. It also makes it easier (almost free) to have testing for backward compatibility if we just add tests.

I second the matching logic that @n3wscott recommends for 2.* versions as well. I think we can use that while still getting the backward compatibility tests "for free".

For 3.* versions, I don't think we can predict what those tests will look like because we can't predict what the spec will look like, but I do think we can at least take the semver matching logic and use it in the 3.x tests. Possibly the path matching logic too

@mattmcneeney
Copy link
Contributor Author

Hey @jeremyrickard - do you still have time to look into the re-architecture of this framework soon?

@jeremyrickard
Copy link

@mattmcneeney I started looking at this but then got caught up doing some higher priority things, so I haven't really made much progress on it.

@leonwanghui
Copy link
Collaborator

Please put me in if we start the design, thx!

@leonwanghui
Copy link
Collaborator

@norshtein @zhongyi-zhang Any thought on this issue? I think semver is a good suggestion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Inbox
Development

No branches or pull requests

5 participants