Skip to content

Add compatibility tests #1574

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

Open
ehuss opened this issue Jun 9, 2021 · 2 comments
Open

Add compatibility tests #1574

ehuss opened this issue Jun 9, 2021 · 2 comments
Labels
A-testing-mdbook-iteself Area: mdbook's testsuite and unittests E-Help-wanted Experience: Help Needed

Comments

@ehuss
Copy link
Contributor

ehuss commented Jun 9, 2021

I think it would be good to have some tests that validate the preprocessor and renderer interfaces remain compatible with plugins built with older versions. That could help catch regressions like #1571 and others.

@ehuss ehuss added the A-Tests Area: `mbdook test` related tests label Jun 9, 2021
@ehuss ehuss added E-Help-wanted Experience: Help Needed A-testing-mdbook-iteself Area: mdbook's testsuite and unittests and removed A-Tests Area: `mbdook test` related tests labels Jul 6, 2021
@earv1
Copy link

earv1 commented Jul 19, 2023

Hey there, I'm interested in your project as a first time contributor. I started looking at this, but it seems like this might already be solved by #1897. Is there anything still missing?

@ehuss
Copy link
Contributor Author

ehuss commented Jul 19, 2023

That doesn't quite do what I was thinking about for this issue. That has a hard-coded input that applies to the current preprocessor. The intent here is that the current mdbook's output can be consumed and processed by an old preprocessor (and renderer).

I'm not sure how the test could be best structured, but essentially I was thinking that there would be a preprocessor and renderer that just assert that their input matches a hard-coded value. The test would run mdbook against that preprocessor/renderer combination, and if either fail, then the test fails. That would help detect if mdbook starts generating different structures.

I'm not sure how maintainable that is, I haven't thought about it too much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testing-mdbook-iteself Area: mdbook's testsuite and unittests E-Help-wanted Experience: Help Needed
Projects
None yet
Development

No branches or pull requests

2 participants