I have got many objects with techniques that need database access. We are searching to get involved with unit testing but they are keen to prevent using mock objects if at all possible. I am wondering if there's a method to refactor the Validate method proven below to ensure that it can't need db access. In the application there's often a lot more happening however i think this simplified example ought to be enough.

We'll learn how to use mock objects if we have to however it just appears like lots of overhead, so I am searching for options.

    public class Person
    {
        public string Name;

        public string Validate()
        {
            if (PersonDA.NameExists(Name))
            {
                return "Name Already Used";
            }

        }
    }

Personally I'd go the mock object route. It's a lot more flexible also it seems like you are attempting to go the path of putting test code inside your actual object?

Regarless, extract the validation code right into a PersonValidator object having a way of boolean isValid(Person). Then within the test code make use of a mock validator which just returns true or false in line with the test situation.

The Individual class is difficult to unit-test because it features a hidden, static reliance upon database access code. You are able to break this coupling by presenting an engaged collaboration between your Person plus some new kind of object that accounts for the data it must validate its condition. Inside your unit tests of the individual you can look at what goes on when it's valid or invalid without striking the database by passing the individual object "stub" implementations of it's collaborator.

You can look at the actual implementation, which hits the database, inside a separate group of tests. Individuals tests is going to be reduced but there must be less of these because they'll be direct translations of accessor techniques to database queries without any complex logic that belongs to them.

You are able to call that "using mock objects" if you want but, since your current design means you only have to stub queries, not expect instructions, a mock object framework is really a too complicated tool to do the job. Hands-written stubs can make test failures simpler to identify.

Have a look at dbunit, it's especially established to populate a little test database so that you can make use of your real objects on the mock database throughout unit testing. Testing by using it is way simpler than developing mock objects, far safer than modifying your computer data access code, and more thorough than either.

You need to just setup a database that's employed for the system testing. If you are using mockups for the data access, you would not really be testing much? :)

The reason for attempting to avoid mocks exactly? If you are planning to rehearse unit testing and you've got data access code, its likely to be simplest to obtain confident with the mock/stub/inject method of doing things.

Whether it's since you shouldn't generate a mocking framework you can code up some simple stubs since you need them.

Putting your computer data access code behind an interface will let to prevent the requirement for a database. Think about using dependency injection to place the mock or stub data access code throughout your results.

Refactored Code :

Person is simply a POJO.

//POJO
public class Person {
        public String Name;
}

PersonValidator may take inside a Person or perhaps a reputation for validation.

//Validator Service for Person
public class PersonValidator {

private PersonDA personDA;

public PersonValidator (PersonDA personDA) {
    this.personDA = personDA
}

public String validate(String name) {
  if (personDA.nameExists(name)) {
       return "Name Already Used";
  }
}

}

For my Testing I'm able to pass inside a dummy implementation of PersonDA . You will possibly not need to use any Mocking Framework, but nonetheless the idea of mocks are participating.