The system I am working has (fortunately) JUnit unit tests already, which are covering some percentage of the code functionality (Better than nothing, I suppose).
The methods in the system are highly dependent to each other and the combination of the parameters that can be sent to a method as an input is huge. Let's see an example:
public void showMessage (final Language language, final Applications apps, final UserID userId)
The above method can have more than 300,000 different messageboxes poping up, based on different apps and userIds. Apart from the fact that whether putting such huge pressure on a single method a couple of them at least, sounds resoanable or not (which IMO cannot be justified design-wise), we are encountering the fear of a bug which can cause huge problems.
That being said, what we found is simply is as follows:
- Refactoring JUnit Unit Tests
- Extract a lot of objects in the method as parameters
- Create an Object Factory
- Feed the unit tests with different inputs created by the factory (brute-force test, maybe?)
- Check the outcome of the newly refactored tests
So basically, the question is as follows:
Creating Integration Tests on top of Unit Tests: Possibilities and Challenges? Is this a customized approach or this is a rational standard approach? Where to put such tests in both the project files and project build lifecycle, should they be built all the time to complete the build process?
Any type of feedback/comment, both from JUnit implementation limitations and Design/Idea limitations.