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

[fontc] More code reuse in fontc tests #584

Merged
merged 1 commit into from
Nov 21, 2023
Merged

[fontc] More code reuse in fontc tests #584

merged 1 commit into from
Nov 21, 2023

Conversation

cmyr
Copy link
Member

@cmyr cmyr commented Nov 17, 2023

In the process of looking into how to add mark-mark tests I got a bit distracted trying to figure out a way to reduce the boilerplate in the existing tests.

This mostly does that, although it also slightly tweaks how some asserts are structured.

@cmyr
Copy link
Member Author

cmyr commented Nov 17, 2023

Also as a general observation (not having really looked at this in much detail before) a bunch(/most/all?) of the tests in lib.rs really feel like integration tests, which can potentially live outside of the crate in the tests directory, assuming that they don't need to access much private internal API. I will put this on my 'one day' todo list...

///
/// When you need more control, just the `compile` fn/`TestCompile` type
/// directly
struct SimpleCompile {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the elimination of boilerplate but I'm not sure why you need a new type, just improve TestCompile?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Filed as #594 to unblock merging

Copy link
Contributor

@rsheeter rsheeter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with one nit

@cmyr
Copy link
Member Author

cmyr commented Nov 20, 2023

I looked into that, and it isn't obvious how to present this sort of simple interface there, while preserving the flexibility of the existing type. This solution doesn't feel great, but it does feel like a small improvement.

fn new(source: &str) -> std::io::Result<Self> {
let temp_dir = tempdir()?;
let build_dir = temp_dir.path();
let result = compile(Args::for_test(build_dir, source));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't particularly like that the heavy-lifting part of the code where things get compiled is hidden in a default new() constructor.. Why not use a free function that takes a str and returns a struct and is named with something like "compile" to make it clear this is, well, compiling?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, I like the current result = compile() pattern. I also like how this PR removes some of the boilerplate. Seems possible to combine.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fair, how about SimpleCompile::compile?

@cmyr
Copy link
Member Author

cmyr commented Nov 21, 2023

okay I'm inclined to get this in, it isn't a silver bullet but it marginally improves the status quo

@cmyr cmyr added this pull request to the merge queue Nov 21, 2023
Merged via the queue into main with commit 27530cd Nov 21, 2023
10 checks passed
@cmyr cmyr deleted the test-setup-reuse branch November 21, 2023 21:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants