Property testing: Strategic automation for devs and SDETs

Комментарий Программного комитета:

Заходит однажды тестировщик в бар и заказывает:

• кружку пива,
• 2 кружки пива,
• 0 кружек пива,
• 999999999 кружек пива,
• ящерицу в стакане,
• –1 кружку пива,
• qwertyuip кружек пива.

А Джессика расскажет, как сделать такие тесты проще и удобнее.

Property testing has been discussed as the next logical step to augment unit tests. While unit tests are typically written to assert a single condition, property tests are written to assert multiple conditions within a set range that would apply to the specific unit of code under test. By learning to write property tests, developers and SDETs can get more mileage out of unit tests by either using random libraries to test ranges of inputs over time, or in some cases automating testing for a specified series of inputs.

While this type of testing has been specified in UI testing (testing a feature using scenario outlines and data tables in Cucumber, for example), it is less common in unit and integration level tests. Yet, tests throwing a lot of data at a specific area of code are significantly less expensive to create and run in a property testing framework than in a UI framework. Thus, it is beneficial to consider how property testing can create value in our automation framework.