mirror of
https://github.com/xoofx/markdig.git
synced 2026-02-03 21:36:36 +00:00
Find a way to regenerate Spec.cs when Specs\*.md changes #179
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @leotsarev on GitHub (Jan 8, 2018).
Expected result: Specs.cs was automatically updated
Actual result: You have to manually run Specs.tt custom tool to perform that.
P.S. Also Specs.cs probably should be excluded from source control
@xoofx commented on GitHub (Jan 8, 2018):
That's a limitation of
ttfiles, so there is no real workaround for this.ttfiles cannot be triggered at build time, they are design time only, so you need to go through the saving whenever there is an update to an indirect files.A different way to do it would be to generate the tests on the fly, by loading the specs when launching the tests and create the tests from there, but in my experience, it can make the test loading more laborious and less reactive (and not displayable if you don't try to run the tests...)
The process of updating the specs is not common, so it is not that critical, and if you are aware of the workflow in this case, you will not forget to resave the Specs.tt file
@leotsarev commented on GitHub (Jan 8, 2018):
According to Google, there is some solution
https://stackoverflow.com/a/24274820/408666
I'm not explored this yet, so I just leave this link here for future me (or you or any other guy) to explore
@xoofx commented on GitHub (Jan 8, 2018):
Yeah, sure you could run the T4 template process on your own, but frankly, that's a laborious process to setup, not really a typical usage with tt files. Again, once you know the workflow of updating the md specs files, it is not that annoying.
@leotsarev commented on GitHub (Jan 8, 2018):
I don't like commiting generated file :-)
But it probably my preference and it's for you to decide.
@xoofx commented on GitHub (Jan 8, 2018):
On that matter, I generally agree with this statement 😉
If you want to try to generate the test on the fly by moving the specs loader from tt to the tests directly, you can try and see how it goes. As I have personally little bandwidth/interests on this matter, PR welcome.
@leotsarev commented on GitHub (Jan 8, 2018):
See PR.
It seems to discover same number of tests.
I don't know of other way to test it.
@leotsarev commented on GitHub (Jan 28, 2019):
Probably can be closed.