Question

Our team is pretty new with testing. We are using scrum for the first time.
In the first sprint we are having 1 button on the gui. Pressing the button will cause to translate the content of a text file to a database (in a new thread/task). The gui will show the task is started and will poll for the state of the task.

We know how to unit test everything by using the TDD method. But when done we have to make integration tests.

What kind of tests do wee need execute in an integration test?
Do we need to check everything in the database is filled correctly by testing different files?
(IE: relationships, specific format which is stored as varchar(xxx), etc?)

If so: This could be pretty complex right? Because you dont have 1 or 2 input parameters, but you have a whole file (the content of the file i mean!!!) which is variable to test. You could make hundreds, or maybe thousands of tests for this one button press then. Worst thing: Most of those tests (i.e. formatting) is already tested on unit tests.

Most examples on internet show more gui like tests as integration test (or are the examples below acceptance tests?):
Login with correct username and password
– Input: name + password
– Expected output: A redirect to homepage

Login with incorrect username and/or password
– Input: name and password (incorrect)
– Expected output: A warning (login failed, incorrect username or password)

Answer 1

Your question covers MANY areas of trying to move to a better procedure for testing and environmental building. So to start with lets just touch on integration tests.

For integration tests you want an empty database for the most part, as you are testing that given a specific set of data existing you can query that data and get the desired result.

Lets use a simple example like a UserFinder class, you want to be able to find a user within the system with a given name and get a usable model back.

public class UserFinder
{
    private SomeDbContext _dbContext;

    public UserFinder(SomeDbContext dbContext)
    { _dbContext = dbContext }

    public User FindUser(string name)
    { _dbContext.Find<User>(new FindUserByNameQuery(_dbContext, name)); }
}

Now in the above although its a pretty rubbish class we could test that given a user in the database with the name “Tester” that when you call FindUser(“Tester”) you should get back that user model.

So as part of this test you would want to start by setting up the expected user in the database, then you would create your user finder giving it a real database connection, then you would query the database with the name “Tester” and prove that you get that model back.

This way you can run that test in any context, be it the IDE a build script or command line, and you will get consistant results because your test is self contained, it sets up the scenario, runs the test and validates the acceptance criteria. Then once that test is done all data should be removed, the whole point being that you set up ONLY what you need for a given test, and generally set it up ONLY within that test.

Now ideally as integration tests and acceptance tests are alot slower to run than unit tests you only really want to test things that are not covered in a unit test, however at the same time you want to make sure you only test YOUR logic, like you could easily create the test scenario above using NHibernate and all you would prove is that NHibernate works, which is not the goal for you. It is impossible for US to tell YOU what you need to test as we dont know your project or what you are trying to achieve, but you should have some idea of your applications flow of logic, and if you see any points in that flow where it connects to a database or file system or passes over some other external boundry to the application where you have business logic, you probably want to put a test scenario in.