Problem There might be situations, when you need to seed some data with keeping the business logic in mind. Applying business logic and versioning of SQL migration scripts can be time-consuming. We should not forget about it would be great to be able to trace back the changes done in the database. Examples * You got a legacy project with a db schema you know you will need to modify during your upcoming implementations. You also know that, you will need to move some data from one table to another by applying business logic to it just before the app starts up for the first time with the latest migrations. * You have a missing feature in your system, and you have a repetitive data manipulation (inject) task. For example, you need to modify user access controlled via db tables, because you do not have a UI, feature in the app to do so. You also would like to apply the business logic regarding the User Access of the project and you also would like to be able to trace back who modified user
What is test automation? Wikipedia says: 'In software testing , test automation is the use of software separate from the software being tested to control the execution of tests and the comparison of actual outcomes with predicted outcomes.' Therefore, we automate the way how we - the user or just a consumer of an API - uses the application. There are two big groups: GUI testing When we do automated testing in this group, then we actually record an ordered set of user actions, then we run them against the softer under test, and then we check the result against the expected result. API driven testing When we do automated testing in this group, then we have no GUI. We have only an interface that can be accessed by our automated tests, then we just pass many kinds of parameters into it and verify the results against the expected. Example In our example, we have a SchoolManagerGUI, where the User can change the type of the IKitchenService with a few clicks on the UI. Note that