RE: Generating C# from Java (Was: fit, nfit, et al?)
"Charlie Poole" <[email protected]> Fri, 8 Aug 2003 20:32:37 -0700
| Newsgroups | gmane.comp.programming.tools.fit.devel |
|---|---|
| Message-ID | <[email protected]> |
Ward, > > Do all implementations work with exactly the same tables, as the Java > > and C# versions do? > > The goal is that if test documents required modification when > converting from one language to another, that the modifications would > seem natural given the language and/or environment, not pointless and > due to carelessness of the framework implementors. > > For example, the package names that appear in tables trace their roots > to java package names and preserve the java syntax. When this was > discussed on this list we considered abandoning package names and > searching some sort of "package path" instead. It was pointed out that > an implementation could always do this anyway and that having the > package names in the dot syntax was as good as any other syntax for > "advisory" package names. OK... so the package name could just be a tag in some hypothetical implementation. In that case, the particular fixture implementation that gets loaded depends on which runner is used. > I could easily imagine a whole page of framework acceptance tests (fat) > that discussed the conclusions of that conversation. > > I've found it convenient to write fixtures as inner classes and > discovered that this just worked with the java implementation using the > $ notation. I could easily imagine someone converting my tests to some > environment without inner classes having to edit those tests and cook > up some alternative to inner classes. This alone is probably reason for > me to stop using inner classes. I only did it to see what it was like. It think it would just work with the C# implementation using the + notation. It doesn't seem like a totally bad thing if the content and format of the string varies a bit depending on the implementation you're using... so long as the table data remains the same. That might mean some minimal set of data types being understood by each implementation as well, mightn't it? Charlie Poole [email protected] http://www.pooleconsulting.com http://www.charliepoole.org