4 ms·
> What exactly are you trying to accomplish? Good test must verify the contract on the system boundaries: in case of the API, it's verification done by calling
by ivan_gammel 8y ago
> What exactly are you trying to accomplish?
Good test must verify the contract on the system boundaries: in case of the API, it's verification done by calling the API. We are discussing two options here: integrated application, hosting multiple APIs, and microservice architecture. Verification on the system boundaries means running the app, not running a unit test (unit tests are good, but serve different purpose). Feature flags make it only worse, because testing with them covers only non-production branches of your code.
> Your initial assumptions were incorrect.
With nearly 20 years of engineering and management experience, I know very well how modern testing is done. :)
- scarface74 8y agoVerification on the system boundaries means running the app, not running a unit test What is an app at the system boundaries if not a piece of code with dependencies? If you have a microservice - FooService that calls BarService. The "system boundary" you are trying to test is FooService using a fake BarService. I'm assuming that you're calling FooService via HTTP using a test runner like Newman and test results. In a monolithic application you have class FooModule that depends on BarModule that implements IBarModule. In your production application you use create FooModule: var x = FooModule(new BarModule) y = x.Baz(5); In your Unit tests, you create your FooModuleL var x = FooModule(new FakeBarModule) actual= x.Baz(5) Assert.AreEqual(10,actual) And run your tests with a runner like NUnit. There is no functional difference. Of course FooModule can be at whatever level of the stack you are trying to test - even the Controller.