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

Make *test-object* in test-engine a parameter #199

Open
dbp opened this issue Aug 13, 2023 · 6 comments
Open

Make *test-object* in test-engine a parameter #199

dbp opened this issue Aug 13, 2023 · 6 comments
Labels
test engine topics related to the test engine

Comments

@dbp
Copy link

dbp commented Aug 13, 2023

This looks like something that could be a parameter:

(define *test-object* (empty-test-object))

And if it were also exposed as such, it would be helpful.

As one example: I would like to be able to dynamically load a module and not have it register any of its tests (as the only reason I'm loading it is to grab a definition from its namespace). That would be easy to do if it were a parameter, but seems quite hard currently.

@mfelleisen
Copy link
Contributor

If the loaded file is under your control, organize it differently: Modular Programming

@dbp
Copy link
Author

dbp commented Aug 14, 2023

@mfelleisen it's (by design) not. The application is: https://github.com/dbp/htdp-examplar -- I am taking student submissions, swapping their implementations with reference good/bad ones, putting their implementations into good test suites, etc. There are enough knobs on test-engine that it works, but it's a little clumsy (I pass around test suites, initialialize-test-object! very frequently, etc).

@mfelleisen
Copy link
Contributor

OK, let's see what @mikesperber says.

@mikesperber
Copy link
Member

I am sympathetic to solving your problem, but am not sure a parameter is a good fit for your use case. @dbp could you elaborate where the use case is coming from, and possible others?

@dbp
Copy link
Author

dbp commented Aug 18, 2023

@mikesperber All my uses are actually in the code linked above. You can see, e.g., here: https://github.com/dbp/htdp-examplar/blob/297e0776c25dbd13af8605eb69cd2e799b589c0a/main.rkt#L60 -- I have copied the tests earlier (by initializing, loading the file, and then grabbing what is returned by current-test-object), and now am running them, one at a time, by initializing, adding, running. The code works, but it feels a bit clumsy (or if not clumsy, very imperative).

Part of that is that I can only modify the current set of tests by either initializing or adding a single test, but another part is that getting tests from a file involves loading the file, which then mutates global state (and only happens the first time the file is loaded).

@mikesperber
Copy link
Member

@dbp Ah, I see. Thanks! Turning this into a parameter doesn't really change the imperativeness, I feel, and complicates the semantics wrt. threads.

So I'd rather provide something more high level.

Would a dynamic form where you do:

(call-with-test-engine-disabled
  (lambda ()
    <your code>))

also work for you?

@shhyou shhyou added the test engine topics related to the test engine label Nov 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
test engine topics related to the test engine
Projects
None yet
Development

No branches or pull requests

4 participants