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.
- Restructure e2e test folder structure - Add e2e test readme/build instructions - Move installed temp files to $env:TEMP or equivalent - Do as many checks as possible before creating Process() object
| var response = await GetResponseMessage(request); | ||
|
|
||
| Console.WriteLine( | ||
| $"InvokeHttpTrigger: {functionName}{queryString} : {response.StatusCode} : {response.ReasonPhrase}"); |
There was a problem hiding this comment.
Will console logs be captured in the test output? Normally we write logs in Xunit to ITestOutputHelper.
There was a problem hiding this comment.
Deleting this whole method as it is never used and - IMO - we should rely on the Task method and validate responses in tests or methods defined in test classes
| string actualMessage = await response.Content.ReadAsStringAsync(); | ||
| Console.WriteLine( | ||
| $"InvokeHttpTrigger: expectedMessage : {expectedMessage}, actualMessage : {actualMessage}"); | ||
| return actualMessage.Contains(expectedMessage); |
There was a problem hiding this comment.
Could/should we use Assert.Contains(...) here instead?
There was a problem hiding this comment.
Deleting this whole method as it is never used and - IMO - we should rely on the Task method and validate responses in tests or methods defined in test classes
| <ItemGroup> | ||
| <FrameworkReference Include="Microsoft.AspNetCore.App" /> | ||
| <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" /> | ||
| <PackageReference Include="Microsoft.Azure.WebJobs.Extensions.DurableTask" Version="3.0.2" /> |
There was a problem hiding this comment.
Is there a particular reason to include the WebJobs package reference here? Normally .NET Isolated apps should never reference WebJobs packages directly.
There was a problem hiding this comment.
Will address along with the work to update to package references
There was a problem hiding this comment.
Done - now the test app has a reference to the worker extension project only. The webjobs extension is still packed and put in a local nuget packages folder alongside the app, so that the WorkerExtensions.csproj can get the version it needs
Direct commit applicable PR suggestions Co-authored-by: Chris Gillum <cgillum@microsoft.com>
- file-scoped namespaces - Remove unneeded .gitignore lines - using statements for HTTP objects where applicable - small readme improvements
test/e2e/Tests/build-e2e-test.ps1
Outdated
| } | ||
|
|
||
| # Write-Host "Updating WebJobs.Extensions.DurableTask version to $webJobsExtensionVersion" | ||
| # dotnet add app.csproj package Microsoft.Azure.WebJobs.Extensions.DurableTask --version $webJobsExtensionVersion |
There was a problem hiding this comment.
Can these commented-out lines be removed?
andystaples
deleted the
andystaples/isolated-integration-testing-framework
branch
Pull request checklist
pending_docs.mdrelease_notes.md/src/Worker.Extensions.DurableTask/AssemblyInfo.cs