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

break up the runtestprotocol and create a sequence of setup/teardown/call actions #895

Open
RonnyPfannschmidt opened this issue Jul 27, 2015 · 8 comments
Labels
type: backward compatibility might present some backward compatibility issues which should be carefully noted in the changelog type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature
Milestone

Comments

@RonnyPfannschmidt
Copy link
Member

the current usage of setupstate and runtestprotocol creates problematic quirks with tear-down,
to elevate that problem and separate reports better, we should instead have a generator for setup/teardown actions and use those to report setup of items and fixtures as well as the running of items

that way we could remove the need for next-item and ensure each report is much more specific

@RonnyPfannschmidt RonnyPfannschmidt added this to the 3.0 milestone Jul 27, 2015
@The-Compiler
Copy link
Member

I don't understand this issue, but I doubt it should block 3.0. Let me know if you disagree.

@The-Compiler The-Compiler modified the milestones: 3.1.0, 3.0 Aug 5, 2016
@RonnyPfannschmidt RonnyPfannschmidt modified the milestones: 4.0, 3.1.0 Aug 5, 2016
@Zac-HD Zac-HD added the type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature label Oct 20, 2018
@nicoddemus nicoddemus modified the milestones: 4.0, 4.1 Nov 22, 2018
@nicoddemus
Copy link
Member

@RonnyPfannschmidt is this something you want to tackle for 4.1 or 4.2 still?

@RonnyPfannschmidt
Copy link
Member Author

@nicoddemus i beelive its more of a 6.0 or 7.0 thing - it will require breaking changes

before delving into it i'd like to resolve config, nodes and storage apis since doing it before would incur really bad and strange tech debt

@RonnyPfannschmidt RonnyPfannschmidt modified the milestones: 4.1, 6.0 Dec 19, 2018
@RonnyPfannschmidt RonnyPfannschmidt added the type: backward compatibility might present some backward compatibility issues which should be carefully noted in the changelog label Dec 7, 2019
@nicoddemus
Copy link
Member

@RonnyPfannschmidt I'm moving this for the 7.0 milestone (just so we don't lose sight of it, I believe this will take more work even for 7.0 still).

@nicoddemus nicoddemus modified the milestones: 6.0, 7.0 Jun 7, 2020
@RonnyPfannschmidt
Copy link
Member Author

This huge chuck will stay with us longer than we wish

@h-vetinari
Copy link

@RonnyPfannschmidt: before delving into it i'd like to resolve config, nodes and storage apis since doing it before would incur really bad and strange tech debt

Are there tickets already for how config / node / storage APIs would need to be changed to be able to do this? If not, could you write up what you think is necessary?

@RonnyPfannschmidt
Copy link
Member Author

We have a couple of issues and projects about it

It's unlikely I can work on this before February
/March

@h-vetinari
Copy link

Projects was the right place to look, thanks! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: backward compatibility might present some backward compatibility issues which should be carefully noted in the changelog type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature
Projects
None yet
Development

No branches or pull requests

6 participants