search

paulirwin / JavaToCSharp

Java to C# converter
MIT License
266 stars 90 forks source link

Add an xUnit test which uses an embedded resource file for testing full Java and C# code examples #28

Closed willibrandon closed 1 year ago

willibrandon commented 3 years ago

For testing large files like we would be doing for full Java and C# code examples, I've found this helpful, where you can have your inputs and expected values be embedded resources, with xUnit's [Theory] attribute: https://patriksvensson.se/2017/11/using-embedded-resources-in-xunit-tests/

Originally posted by @paulirwin in https://github.com/paulirwin/JavaToCSharp/issues/13#issuecomment-870617096

willibrandon commented 3 years ago

I can work on this one if you do not mind.

paulirwin commented 3 years ago

@willibrandon Please do!

paulirwin commented 1 year ago

@willibrandon I know it's been a... checks notes couple years... but I wanted to check in to see if you were still interested in this one. If not I might knock it out.

We now do have an xUnit Theory test but it just makes sure that it parses and transforms into something without error; it doesn't confirm that it's even remotely correct.

What I'd like to do is have these test examples be small CLI apps where the unit test can load in the Java code, translate to C# including a Main entry point, actually compile it to an assembly with Roslyn, execute the assembly, and assert the output. I'm doing something similar on some of my other projects like https://github.com/paulirwin/jaktnat (which was further driven by how they do it for Jakt).

This way, we can go beyond just making sure it parses and transforms without error, we can actually assert the correctness of the translation. Let me know your thoughts and if you have time to work on this soon. Thanks!

paulirwin commented 1 year ago

I went ahead and added a "hello world" example of this. It will convert the Java to C#, compile it into an assembly with Roslyn, execute it capturing the output, and assert that the output matches a comment in the header of the Java file with the expected output. Of course it might not be possible to get 100% coverage of these, but hopefully these will help ensure compatibility. I also had to enable #18 in order to support that, as System.@out.Println is not valid in .NET.

Closing this for now, but I welcome future PRs adding additional integration tests!