Frage

In system testing, a software system is tested against requirements.

In unit testing, a software module is tested against the internal requirements for this module which depend on the specific software design and are not visible to the users in general.

I don't like the term internal requirement because a requirement is normally something that is visible to the users of the software and does not depend on its internal structure.

Is there an unambiguous and commonly used term for these internal requirements?

War es hilfreich?

Lösung

The name is "contract". It refers to the pre-conditions and post-conditions of each method, as well as invariants that are true (pre and post conditions for) all methods, including construction.

If you are using a language or tools that can perform automated contract proofs for you, you will be writing a lot less boring detailed tests. You will still need some at a higher level.

Andere Tipps

In the V-Model, the project definition and design activities of increasing detail are mirrored by test and integration activities. There is a relation between design artifacts and the tests that are based on these artifacts.

The V-Model, based on material by the ISTQB

Unit tests (= component tests) are there based on the component specification document.[1] This allows test suites to be created by testers in parallel to the programming effort.

[1]: Compare section 2.2.1 Component Testing in the ISTQB Foundation Level Syllabus 2018.

While this diagram is useful to understand different test levels, it does not match the reality of most software projects: the V-Model is effectively unheard of in most parts of the industry. Many projects will never create explicit design documents or specifications, especially in unstructured or agile environments.

Yet having a record of requirements is useful. TDD and BDD suggest: the test is the specification. BDD style tests can be interpreted as executable documentation, requirements specification, and acceptance test all in one. TDD style tests are a complete specification of a component.

So to answer your main question: I'd suggest that unit tests are based on a detailed design or a component specification, whether these are explicit documents, explicit but the same as the test, or just implicit.

Lizenziert unter: CC-BY-SA mit Zuschreibung
scroll top