SSISIntegrationTesting | writing integration tests for an SSIS project | Database library

SSISIntegrationTesting is a C# library typically used in Database applications. SSISIntegrationTesting has no bugs, it has no vulnerabilities and it has low support. You can download it from GitHub.

This project gives an example of how to go about writing an automated test around an SSIS package. The database is often the place where a lot of mocking is used in application testing as it can be hard to write good repeatable tests around it. The reason for this is that often there are only a few living instances of a database (dev, qa, prod) and everyone just crams there changes into. Normally they are not kept in source control and so are hard to know what state they are in at any one time. By pulling your database into source control and being able to build it as part of a test solves a number of problems: *) You can write full stack integration tests that include your database (no mocks needed which are often brittle and are tightly coupled to the implementation) *) Your database can be fully built by any developer so each person can work independently. Trying out their changes locally before they deploy them to an integration environment *) Reduces test time as a developer finds out straight away if their database changes do not work *) Saves wasting time fixing "ghost" issues, when using a shared database a lot of headaches are caused by many developers changing the database. Meaning you are running code against a different version of the database to what the code expects. This slows down development and often means you are chasing your tail looking for why the code does not work. From the above we can see the advantages that being able to fully build and test your database gives you. So how do we go about writing integration tests for SSIS packages?. SSIS packages are of course often dependent on databases, their most common use case is for an ETL job to move vast quantities of data into a data warehouse database. Obviously, we cannot use this large dataset for test purposes. This project lays out a proof of concept of how you could test an etl job that moves data between two databases. The MyProject SSIS project includes Package1.dtsx. This is a very simple package that takes data from a table called products in a source database and puts it into a table called products in a destination database. Obviously in a real world example the job would be more complex but it gives us something to work with. The key to making the SSIS package testable is by parameterizing the connection strings that are set for the source and destination databases in the connection manager. In the Package1.dtsx the source and destination connection string are passed in by the Source_ConnectionString and Dest_ConnectionString parameters respecitively. If none are passed in then the defaults are used by the package.