My teammates have now understood(!?) the difference between integration testing and unit testing. Now in our project a test assembly is established for each assembly.
Integration tests are currently written without a special framework like SpecFlow or Cucumber. They are plain (and long) NUnit test methods where several classes from different assemblies are tested together.
The plan is now to categorize the tests by Attributes (C #) using "Unit Test" and "integration test", so that NUnit can filter the appropriate tests when necessary.
Is it opportune to mix integration tests and unit tests in the same assembly or should they always be separeted in different assemblies?
Technically this may work but why would you want to do that?
While Unit tests are to test a "unit" which may be a function or any other small piece of code inside the assembly to which your test assembly belongs (One test-assembly for each assembly), an Integration test is about testing some logic which is usually implemented in more than one assembly, so having an extra assembly for the integration tests and keeping them separated from unit tests is actually a better configuration in my eyes.
Read this from some related article:
Integration Testing While unit tests verify the functionality of a piece of code in isolation, integration tests verify the functionality of a piece of code against a target system or platform. Just like unit tests, integration tests are automated procedures that run within a testing framework. Although comprehensive unit testing verifies that your code behaves as expected in isolation, you still need to ensure that your code behaves as expected in its target environment, and that the external systems on which your code depends behave as anticipated. That is where integration testing comes in. Unlike a unit test, an integration test executes all code in the call path for each method under test—regardless of whether that code is within the class you are testing or is part of an external API. Because of this, it takes much longer to set up the test conditions for an integration test. For example, you may need to create users and groups or add lists and list items. Integration tests also take considerably longer to run. However, unlike unit tests, integration tests do not rely on assumptions about the behavior of external systems and services. As a result, integration tests may detect bugs that are missed by unit tests. Developers often use integration tests to verify that external dependencies, such as Web services, behave as expected, or to test code with a heavy reliance on external dependencies that cannot be factored out. Testers often also develop and use integration tests for more diverse scenarios, such as security testing and stress testing. In many cases, organizations do not distinguish between integration and unit testing, because both types of tests are typically driven by unit testing frameworks such as nUnit, xUnit, and Visual Studio Unit Test. Typically, organizations that use agile development practices make this distinction, because the two types of tests have different purposes within the agile process.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With