-
Notifications
You must be signed in to change notification settings - Fork 25
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
Override steps and checks on a per check basis #35
Comments
Have you profiled the test?
This is definitely an option, but I am vary of changing the I was thinking maybe doing something like rapid.WithExamples(...).WithOptions(...).Check(t, func(t *rapid.T) {
// ...
}) but am not sure about it yet. Another option is to use something like |
Oh yes we know who the culprit is. We just started using A small example would be: type User struct {
// ...
}
// This is the real service doing queries against the database
type UserService struct {
// holds connection to the database
}
func (UserService) Insert(context.Context, User) error {}
func (UserService) FindByID(context.Context, string) (User, error) {}
func (UserService) FindAll(context.Context) ([]User, error) {}
type UserStateMachine {
real UserService
users map[string]User
}
// Sets up a database for the test and creates the stub and real instance
func (UserStateMachine) Init(*rapid.T)
// Inserts a drawn User with a non-existing ID (so we know this should succeed)
func (UserStateMachine) InsertNonexisting(*rapid.T)
// Inserts a drawn User with an existing ID (so we know this should fail)
func (UserStateMachine) InsertExisting(*rapid.T)
// Find a User with a non-existing drawn ID (so we know this should find none)
func (UserStateMachine) FindByIDNonexisting(*rapid.T)
// Find a User with an existing drawn ID (so we know this should find one)
func (UserStateMachine) FindByIDExisting(*rapid.T)
// Check calls FindAll
func (UserStateMachine) Check(*rapid.T) The nice thing now is we can create a stub of the UserService, and test it against the same state machine, and we know it will behave the same as the real UserService. So for other tests depending on the UserService, we can use the stub and know it behaves like the real deal. I like the |
fa75bd5 lowers I'll wait before adding |
Thank you! That's perfect for us. |
@pierre-fastly I am a bit vary of implementing full #38 (seems to be a bit out of line with how usual Go tests are configured/run), but I think 4391f11 is a neat trick that should help avoid the need to configure checks or steps manually. Does it look helpful for your use cases? |
I like that indeed! Is there a way to configure the deadlines from the command line? |
AFAIK until golang/go#48157 is implemented, only via existing global |
My use case is I have a very long test case and running it with 100 checks and 100 steps take more than 10 minutes. I'm fine running it every now and then for that long but I'd like to, by default, reduce the number of checks and steps for just this check and leave the default for the other checks.
I'm thinking the best behavior would be command-line flags take precedence over overrides which in turn take precedence over default values.
Is this something you thought about already? Would you be open to adding this feature?
After looking at the source code, we definitely need to make the
flags
variable local and pass it tocheckTB
rapid/engine.go
Line 119 in 110d7a5
flags
variable in any way we want.One way that could make sense to customize the
flags
variable is to change the signature ofCheck
to take in a variadic argument. This would make the change backwards compatible:And have a few helpers:
If you're okay to add this feature, I'll submit a PR with a possible implementation.
The text was updated successfully, but these errors were encountered: