Add integration test framework for isolated #3000
Conversation
- One app with basic "Hello Cities" scenario
andystaples
force-pushed
the
andystaples/isolated-integration-testing-framework
branch
from
2e4c00e to
9a68303
Compare
There was a problem hiding this comment.
I suggest a slightly revised file structure for this, basically putting all end-to-end related code under a test/e2e directory.
/test/e2e/Apps/DotNetIsolated/App.csproj
/test/e2e/Apps/DotNetIsolated/...
/test/e2e/Tests/E2ETests.csproj
/test/e2e/Tests/...
In the future, we can add other language-specific apps under the /test/e2e/Apps/ directory too.
| { | ||
| public static Process GetFuncHostProcess(bool enableAuth = false) | ||
| { | ||
| var funcProcess = new Process(); |
There was a problem hiding this comment.
nit: let's wait to create the Process object until the time when we're actually use it. This is especially important for disposable objects, like Process, which can cause memory/handle leaks if they are created but not disposed (which will happen if you create it and we throw an exception in line 25 or line 39).
|
|
||
| var e2eAppPath = Path.GetDirectoryName(e2eHostJson); | ||
|
|
||
| var cliPath = Path.Combine(rootDir, @"test/DotnetIsolatedE2ETests/Azure.Functions.Cli/func"); |
There was a problem hiding this comment.
This seems to imply that the func.exe tool is checked into the repo, which I assume is not your intention. I recommend putting it into a temporary directory instead.
There was a problem hiding this comment.
func isn't checked into the repo, but running the build-e2e-test.ps1 script will install it into this location. Useful for several reasons -
- Durable "power users" often modify the Core Tools in the PATH, we want an unmodified copy running for these tests
- Pipeline automation will have to take this step anyway, might as well do it in this script
There was a problem hiding this comment.
I can modify the install directory - but for the pipeline scenario it is most useful to have it inside the repo folder structure somewhere. Dotnet worker does it in the root.
| <FrameworkReference Include="Microsoft.AspNetCore.App" /> | ||
| <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" /> | ||
| <PackageReference Include="Microsoft.Azure.WebJobs.Extensions.DurableTask" Version="3.1.2" /> | ||
| <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.DurableTask" Version="1.3.2" /> |
There was a problem hiding this comment.
Is it possible to add a project reference to the Worker Extensions package like this example instead of referencing a specific version?
There was a problem hiding this comment.
Can we resolve the warnings that are showing up in this PR?
There was a problem hiding this comment.
Can you add a simple README for this project explaining the scripts that we have and how the fixtures and helper files are used?
Pull request checklist
pending_docs.mdrelease_notes.md/src/Worker.Extensions.DurableTask/AssemblyInfo.cs