You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PR (#497) for central configuration implementation doesn't include automated tests - this issue is to add automated tests for central configuration feature.
Unit tests using MockCentralConfigFetcher to simulate dynamic changes in configuration and verify that relevant features of the Agent (at the moment only transaction sampling) reacts to the configuration changes as expected
Tests that run on both Full .NET Framework and .NET Core (and use MockApmServer?)
Note: If we want to use MockApmServer we won't be able to place the tests into Elastic.Apm.Tests because dependecies go into the opposite direction - Elastic.Apm.Tests.MockApmServer depends on Elastic.Apm.Tests.
One possible approach is to create a new test project (for example Elastic.Apm.ComponentTests) that will depend on Elastic.Apm.Tests.MockApmServer and include tests that use only via Agent public API and data Agent sends to APM Server.
An advantage of this approach is that we don't need to allow Elastic.Apm.ComponentTests access to implementation internal-s thus reducing the chance of deviating from real world use cases.
Tests for Elastic.Apm.AspNetFullFramework.Tests to verify that implementation works correctly when running in context of classic ASP.NET application on top of IIS.
It would be nice to re-use the same logic of (scenario, expected outcome) used in the tests from the previous item.
PR (#497) for central configuration implementation doesn't include automated tests - this issue is to add automated tests for central configuration feature.
MockCentralConfigFetcherto simulate dynamic changes in configuration and verify that relevant features of the Agent (at the moment only transaction sampling) reacts to the configuration changes as expectedMockApmServer?)MockApmServerwe won't be able to place the tests intoElastic.Apm.Testsbecause dependecies go into the opposite direction -Elastic.Apm.Tests.MockApmServerdepends onElastic.Apm.Tests.Elastic.Apm.ComponentTests) that will depend onElastic.Apm.Tests.MockApmServerand include tests that use only via Agent public API and data Agent sends to APM Server.An advantage of this approach is that we don't need to allow
Elastic.Apm.ComponentTestsaccess to implementationinternal-s thus reducing the chance of deviating from real world use cases.Elastic.Apm.AspNetFullFramework.Teststo verify that implementation works correctly when running in context of classic ASP.NET application on top of IIS.