-
-
Notifications
You must be signed in to change notification settings - Fork 12
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
Add Test Suite #131
base: master
Are you sure you want to change the base?
Add Test Suite #131
Conversation
There are some issues with executing 'dotnet test' to run the entire test suite, but running individual tests works successfully.
_cliArgs.AddRange(interfaceQuery.Split(' ')); | ||
} | ||
|
||
public void WithBusinessProcesses(string businessQuery) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably need to add checks like this for all options:
if (string.IsNullOrEmpty(businessQuery))
return;
Without this the CLI misinterprets the option values e.g. in ToDoAppExample there are no business processes, but if we add --business-processes
with no values, then it would look as follows --business-processes --levels-of-details container
. CLI treats --levels-of-details container
as values for --business-processes
option.
set => _workingDirectory = value; | ||
} | ||
|
||
public async Task<int> BuildAndInvoke() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably use cmd.exe here to ensure that every test runs in its own process. This would allow us to run all tests concurrently e.g.
public async Task<int> BuildAndInvoke()
{
if (_paramsArg.Count > 0)
{
_cliArgs.Add("--params");
_cliArgs.AddRange(_paramsArg.Select(kvp => $"{kvp.Key}={kvp.Value}"));
}
var args = string.Join(" ", _cliArgs.Select(x => x.Contains(" ") ? $"\"{x}\"" : x));
_logger($"Executing CLI with arguments: {args}");
var cliPath = Path.GetFullPath(@$"..\..\..\..\C4InterFlow.Cli\bin\Debug\net6.0\win-x64");
// Configure the process start info
var startInfo = new ProcessStartInfo
{
FileName = "cmd.exe",
Arguments = $"/C {Path.Combine(cliPath, "C4InterFlow.Cli.exe")} {args}",
RedirectStandardOutput = true,
RedirectStandardError = true,
UseShellExecute = false,
CreateNoWindow = true
};
// Start the process and capture output/error
using var process = new Process { StartInfo = startInfo };
process.Start();
// Read standard output and error asynchronously
string? output = await process.StandardOutput.ReadToEndAsync();
string? error = await process.StandardError.ReadToEndAsync();
process.WaitForExit();
if (!string.IsNullOrEmpty(output))
{
_logger($"Output: {output}");
}
if (!string.IsNullOrEmpty(error))
{
_logger($"Error: {error}");
}
return process.ExitCode;
}
We may want to add "........\C4InterFlow.Cli\bin\Debug\net6.0\win-x64" as a config value for C4Interflow.Specs project, or find a better way to point to C4InterFlow.Cli.exe
Added a test suite for verifying examples. Running the tests individually works fine, but they fail for the whole suite due to the usage of the static AaCReaderContext/AacWriterContext. It's not an issue under normal usages from the commandline, but due to the threaded tests sharing state it comes up.
I have some ideas for resolving that, but it likely would have a non-trivial ripple through the codebase that are out of scope for getting some tests available.
As of right now, I covered the 'draw-diagrams' and 'execute-aac-strategy' runs.