Tag Info

Yes. I call them Contract Tests. One easy way to understand them: Start with tests for a specific implementation of the interface. For example, consider ArrayList implements List. You write tests for ArrayList. One test could be this: testEmptyIffZeroSize: list = new ArrayList() assert list.isEmpty() assert_equals 0, list.size() Notice that ...

Personally I would write a test data generator that generates unique test data and pushes into the database via a direct api call as part of the setup for each test. That way you can run multiple tests in parallel and can scale up your automated test execution. From my experience, if you are using SoapUI, you probably should be calling the applications ...

Instead of using SQL scripts, I would recommend using something like dbUnit for importing your test data. dbUnit will generate database dumps in XML format (this will also allow you database-independent test data). The advantage is that you can write (build) scripts that will import the dbUnit datasets, run the database update SQL scripts on them (if you ...

A simple test strategy can only guarantee a simple assessment of quality. According to James Bach: The purpose of a test strategy is to clarify the major tasks and challenges of the test project. You can (and probably should) expand "tasks and challenges" to mean "goals, activities, deliverables, constraints, risks, and dependencies." Given that, your ...

First of all, it is understandable that a former developer might approach testing in terms of individually testable layers or sub-components. However, as a tester, if you do nothing else, you must verify that the finished product behaves correctly when exercised using whatever interfaces the end-user will use. Everything else is secondary to that -- ...

You are on the right path with the "clean sheet" approach. It would be best if every test runs on empty database and it fills in data in the database as a part of its own fixture. But if you find yourself using a lot of the same kind of the data for a bunch of tests, then a XML import file would be best. Your testsuite should clear the database before each ...

Is there any business statistic functionality in the old and in the new system? If true you can make the same statistic in both versions and compare them. Example: the number of customers should be the same, as well as the revenue of the best and the worst customer,.. These can act as a kind of cheksum that make shure that no critical value is lost.