सार्वजनिक जानकारी से बना चयन मार्गदर्शन। केवल संदर्भ हेतु।
Shouldly एक BDD-शैली की दावा पुस्तकालय है जो Dart और Flutter के लिए है, जो परीक्षण विफलता के समय स्पष्ट, विवरणात्मक त्रुटि संदेशों को प्राथमिकता देता है। यह परीक्षण पठनीयता और डिबगिंग की कार्यक्षमता में सुधार करने के लिए डिज़ाइन किया गया है, इसमें प्राकृतिक भाषा की तरह पढ़ने वाला एक चलने वाला API है। इस पुस्तकालय को विस्तारित किया जा सकता है, जिससे विकासकर्ता अपनी विशिष्ट परियोजना की आवश्यकताओं के अनुसार दावों को कस्टमाइज़ कर सकते हैं। यह सभी प्रमुख प्लेटफॉर्मों का समर्थन करता है, जिसमें Android, iOS, Web, macOS, Windows और Linux शामिल हैं, जिससे यह क्रॉस-प्लेटफॉर्म परीक्षण कार्यप्रवाह के लिए आदर्श है।
उपयोग
पठनीय और बनाए रखने योग्य इकाई परीक्षण लिखना
परीक्षण विफलता निदान में सुधार करना
परीक्षण-आधारित विकास कार्य प्रवाह को बढ़ाना
समान दावों के साथ प्लेटफॉर्म-स्वतंत्र परीक्षण
क्षेत्र-विशिष्ट सत्यापन के लिए असर्टियन तर्क को कस्टमाइज़ करना
मुख्य विशेषताएँ
स्वचालित, मानव-पठनीय असर्ट कथन सिंटैक्स
असफलता पर विस्तृत और सहायक त्रुटि संदेश
विस्तारयोग्य अभिव्यक्ति प्रणाली
सभी फ्लटर प्लेटफॉर्म को समर्थन करता है
स्पष्ट BDD-शैली का API
pub add के माध्यम से आसान एकीकरण
इनके लिए उपयुक्त
बेहतर परीक्षण प्रतिक्रिया चाहने वाले विकासकर्ता
TDD या BDD का अभ्यास करने वाली टीमें
स्पष्ट परीक्षण आउटपुट की आवश्यकता वाले प्रोजेक्ट
क्रॉस-प्लेटफ़ॉर्म फ्लटर एप्लिकेशन्स
टेस्ट ऑटोमेशन इंजीनियर्स
विचार योग्य बातें
नए BDD उपयोगकर्ताओं के लिए सीखने का वक्र आवश्यक हो सकता है
परीक्षण सूट में अतिरिक्त निर्भरता
परीक्षण संदर्भ में सीमित (रनटाइम उपयोग के लिए नहीं)
उत्पादन कोड असर्टशन के लिए उपयुक्त नहीं
कस्टम दावों के लिए सावधानीपूर्वक सेटअप की आवश्यकता होती है
मूल README
संबंधित सोर्स रिपॉज़िटरी के मूल README का स्नैपशॉट। नवीनतम सामग्री के लिए रिपॉज़िटरी देखें।
shouldly is an assertion concept that focuses on
writing assertions as plain English sentences
and giving better error messages when the assertion fails while being simple and terse.
satisfyAllConditions will show all errors at once, not only first fail assertion.
test('should satisfy all conditions', () {
Should.satisfyAllConditions([
() => playerCharacter.nickname.should.as('nickname').not.beNullOrEmpty(),
() => playerCharacter.weapons.should.as('weapons').contain('Staff of Wonder'),
() => playerCharacter.health.should.as('health').be(100),
]);
});
Example report can be:
Expected satisfy all conditions specified, but does not.
The following errors were found ...
------------- Error 1 -------------
Expected nickname
should not be null or empty
but was
''
------------- Error 2 -------------
Expected weapons
should contain
Staff of Wonder
but was actually
[Axe, Sword]
------------- Error 3 -------------
Expected health
should be
100
but was
99
------------------------------------
Custom matchers
For existing one - just create an extension for it
extensionCustomNumAssertionsonNumericAssertions {
NumericAssertionsget beNegative {
if (subject >= 0) {
throwShouldlyTestFailureError('Number\n should be negative');
}
returnNumericAssertions(subject);
}
}
Or more exotic matchers - fot custom types
First, create a Assertions class for your custom type which extends BaseAssertions
classCustomerAssertionsextendsBaseAssertions<Customer, CustomerAssertions> {
// ...CustomerAssertionsget beMarried {
if (isReversed) {
if (subject!.isMarried) {
throwShouldlyTestFailureError('Customer should not be married');
}
} else {
if (!subject!.isMarried) {
throwShouldlyTestFailureError('Customer should be married');
}
}
returnCustomerAssertions(subject);
}
CustomerAssertionsget beMale {
if (isReversed) {
Execute.assertion
.forCondition(subject!.gender == Gender.male)
.failWith('$subjectLabel should not be male');
} else {
Execute.assertion
.forCondition(subject!.gender != Gender.male)
.failWith('$subjectLabel should be male');
}
Execute.assertion
.forCondition(subject!.gender != Gender.male)
.failWith('$subjectLabel should be male');
returnCustomerAssertions(subject);
}
// ...
}
Second, create an extension on your class which has should property with type of your custom assertions class
extensionCustomerExtensiononCustomer {
CustomerAssertionsget should => CustomerAssertions(this);
}
Third, you are ready to go use your own shouldly assertions
test('async function should throw exception', () async {
awaitShould.throwAsync(() {
Future.delayed(Duration(milliseconds: 100));
throwException('test');
});
});
test('async function should throw exact exception', () async {
awaitShould.throwAsync<CustomException>(() {
Future.delayed(Duration(milliseconds: 100));
throwCustomException('custom exception test');
});
});
test('should complete in a duration', () async {
awaitShould.completeIn(
Duration(seconds: 1),
func: () => slowFunction(
Duration(milliseconds: 900),
),
);
});
Enums
test('should not be equal', () {
seasons.spring.should.not.be(seasons.winter);
});
test('should not be type of', () {
seasons.spring.should.not.beOfType<level>();
});
test('should be assignable to `Enum`', () {
seasons.spring.should.beAssignableTo<Enum>();
});
extensionCustomerExtensiononCustomer {
CustomerAssertionsget should => CustomerAssertions(this);
}
classCustomerAssertionsextendsBaseAssertions<Customer, CustomerAssertions> {
CustomerAssertions(
Customer? subject, {
bool isReversed = false,
String? subjectLabel,
}) : super(subject, isReversed: isReversed, subjectLabel: subjectLabel);
CustomerAssertionsget beMarried {
if (isReversed) {
if (subject!.isMarried) {
throwShouldlyTestFailure('Customer should not be married');
}
} else {
if (!subject!.isMarried) {
throwShouldlyTestFailure('Customer should be married');
}
}
returnCustomerAssertions(subject);
}
CustomerAssertionsget beMale {
if (isReversed) {
if (subject!.gender == Gender.male) {
throwShouldlyTestFailure('Customer should be female');
}
} else {
if (subject!.gender != Gender.male) {
throwShouldlyTestFailure('Customer should be male');
}
}
returnCustomerAssertions(subject);
}
@overrideCustomerAssertionscopy(
Customer? subject, {
bool isReversed = false,
String? subjectLabel,
}) =>
CustomerAssertions(
subject,
isReversed: isReversed,
subjectLabel: subjectLabel,
);
}
Recommendations
You can improve the readability of the rest of your test code with given_when_then_unit_test, which enhances the test report readability as well.
Changelog
Please see the Changelog page to know what's recently changed.
Contributing
Feel free to contribute to this project.
If you find a bug or want a feature, but don't know how to fix/implement it, please fill an issue.
If you fixed a bug or implemented a new feature, please send a pull request.