Genbi fails silently on CLI

[fdw]

We want to call Genbi.exe automatically, using the CLI. Unfortunately, errors are silently caught and $? is True, even if the GUI shows an error dialog and no tests have been generated.

Additionally, some log output about the error would be nice to help with debugging.

[FuegoArtificial]

Hello Fabian,

it's indeed difficult to debug. In those cases I've usually reproduced every single step of the script using GenBI and then NUnit. With those tools it's a bit easier to figure out if there is a naming mismatch of fields, some issue with content, invalid XML or also some reserved character which needs an escape (even within some SQL-query sometimes special characters can be annoying like in "<NA>"). At least it's easier to divide and conquer until you find the issue because of the direct feedback if the generation works. Then you can improve a template or whatever causes the issue accordingly. If the generation of the test suite works, testing it in NUnit gives you proper error messages.

It might not be what you are looking for, but maybe it helps.

[fdw]

Thanks for the help, @FuegoArtificial! The main problem is that we can get Genbi.exe to work locally, but not on our agent. So at least the input seems good enough, but even there, we can't be sure.

However, we had a look at Genbi's source and found the right place to at least change the return code: In PlayMacroCommand

        public void ExecuteQuiet(string filename)
        {
            try
            {
                var generator = new TestSuiteGenerator();
                generator.Load(filename);
                generator.Execute();
            }
            catch
            {
                return;
            }
        }

There, errors are silently caught and dropped. Instead, something like Environment.Exit(9) would help. Additionally, we could think about writing the error to a log file, or to include logging of some sort. But I'd like to have @Seddryck's opinion before I'd start implementing something.

[Seddryck]

Yes surely, it's the right place to fix the issue. If you want to write to a log file I would create a new IMacroOutput interface witha method AppendText that the MacroWindow would be implementing but also a new FileLogOutput class.

All pull requests are welcome!