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

Output bug reporting howto if result contains syntax-errors #19

Open
jayvdb opened this issue Jun 26, 2017 · 7 comments
Open

Output bug reporting howto if result contains syntax-errors #19

jayvdb opened this issue Jun 26, 2017 · 7 comments

Comments

@jayvdb
Copy link

jayvdb commented Jun 26, 2017

To allow the tool to be used even with problems like #17 and #18 , I think it would be helpful to do a syntax parse on the generated file before writing it, so files which will be broken can be skipped.

@RonnyPfannschmidt RonnyPfannschmidt changed the title Safe mode dont write unparsable files Jun 26, 2017
@htgoebel
Copy link
Collaborator

To be honest: I don't see much use in implementing this. Spotting this kind of issues is very easy, as they pop up as soon as you try to run your test-suite.

A "savemode" might even make errors like #18 pass unseen, since the test-suite might still run with the unchanged code.

@RonnyPfannschmidt
Copy link
Member

perhaps a better choice is simply to error out if files failed to get fixed in a parsable manner
so people can use the tool and have a working testsuite before and after even if some transformations broke

perhaps allowing a opt-in to write out the unparsable files for manual fixing if intended

@htgoebel
Copy link
Collaborator

perhaps a better choice is simply to error out if files failed to get fixed in a parsable manner

ACK. But for this the fixes need to discover that their have some parse-tree they can not convert. And even then: If a huge test-file contains one construct that can not be handled, erroring out would inhibit the other constructs to be not converted – which I don't think is a good idea.

Anyway, IMHO syntax-errors in the converted files are a no-brainer: trivial to spot and trivial to solve. unittest2pytest is not a silver bullet, but a helper – even it it tries to make the job as good as possible. If we error out or warn about these cases, we get less tickets pointing to fields of improvement.

@RonnyPfannschmidt
Copy link
Member

the error should return a bug reporting howto ^^

@htgoebel
Copy link
Collaborator

htgoebel commented Aug 8, 2017

Rethinking this topic, I can to the conclusion that even unparsable files should be written.

Let's assume in a huge test-file one test can not be converted correctly (produces a syntax error). Now when writing this file to disk, the programmer needs to fix one problem, while if the file would not be written, the programmer would need to convert the whole file manually.

@htgoebel htgoebel changed the title dont write unparsable files Output bug reporting howto if result contains syntax-errors Aug 8, 2017
@htgoebel
Copy link
Collaborator

htgoebel commented Aug 8, 2017

Implementation of the bug reporting howto would be easy:

  • After producing the file, try to compile() it.
  • If compile fails, print a the syntax-error and the howto.

The how-to could be as short as one for two sentences IMO.

@Mattwmaster58
Copy link

Related to #45

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants