100 lines
No EOL
5 KiB
JSON
100 lines
No EOL
5 KiB
JSON
{
|
|
"uuid": [
|
|
{
|
|
"value": "23bff06b-34e8-4f9a-ae67-4405393c874c"
|
|
}
|
|
],
|
|
"langcode": [
|
|
{
|
|
"value": "en"
|
|
}
|
|
],
|
|
"type": [
|
|
{
|
|
"target_id": "daily_email",
|
|
"target_type": "node_type",
|
|
"target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
|
|
}
|
|
],
|
|
"revision_timestamp": [
|
|
{
|
|
"value": "2025-05-11T09:00:51+00:00"
|
|
}
|
|
],
|
|
"revision_uid": [
|
|
{
|
|
"target_type": "user",
|
|
"target_uuid": "b8966985-d4b2-42a7-a319-2e94ccfbb849"
|
|
}
|
|
],
|
|
"revision_log": [],
|
|
"status": [
|
|
{
|
|
"value": true
|
|
}
|
|
],
|
|
"uid": [
|
|
{
|
|
"target_type": "user",
|
|
"target_uuid": "b8966985-d4b2-42a7-a319-2e94ccfbb849"
|
|
}
|
|
],
|
|
"title": [
|
|
{
|
|
"value": "Writing good automated test names\n"
|
|
}
|
|
],
|
|
"created": [
|
|
{
|
|
"value": "2022-11-15T00:00:00+00:00"
|
|
}
|
|
],
|
|
"changed": [
|
|
{
|
|
"value": "2025-05-11T09:00:51+00:00"
|
|
}
|
|
],
|
|
"promote": [
|
|
{
|
|
"value": false
|
|
}
|
|
],
|
|
"sticky": [
|
|
{
|
|
"value": false
|
|
}
|
|
],
|
|
"default_langcode": [
|
|
{
|
|
"value": true
|
|
}
|
|
],
|
|
"revision_translation_affected": [
|
|
{
|
|
"value": true
|
|
}
|
|
],
|
|
"path": [
|
|
{
|
|
"alias": "\/daily\/2022\/11\/15\/writing-good-automated-test-names",
|
|
"langcode": "en"
|
|
}
|
|
],
|
|
"body": [
|
|
{
|
|
"value": "\n <p>Something that I often see in code examples or tutorials are test methods like <code>testGet<\/code> or <code>testAdd<\/code>, or <code>testSubtract<\/code>. Short method names that don't describe the scenario that they're testing in much detail.<\/p>\n\n<p>What if a <code>get<\/code> method returns different types of value based on the input or a string is passed into a calculator method like <code>add<\/code> or <code>subtract<\/code>?<\/p>\n\n<p>I'd assume that the result of the calculation returns the total, but the test method doesn't say this.<\/p>\n\n<p>I'd rather be overly descriptive and write methods like <code>should_add_two_or_more_numbers_and_return_the_total()<\/code> rather than <code>testAdd<\/code>. It's a lot more readable and easier to see what the intention of the test is, and it's much better to use longer descriptive names when using options like <code>--testdox<\/code> with PHPUnit, which converts the method name into a sentence, which is what I do when running tests in CI pipelines.<\/p>\n\n<p>Something that I've picked up and recommend is to start each test case with the word \"It\" or \"Should\". This gives it a more behavioural feel and puts you in the mindset of what you're testing and not the methods that you're executing.<\/p>\n\n<p>A method like 'testAdd' might make sense within a unit test focusing on a single class and method, but as I usually do outside-in testing - which mostly uses functional and integration tests - this approach works well for me.<\/p>\n\n ",
|
|
"format": "full_html",
|
|
"processed": "\n <p>Something that I often see in code examples or tutorials are test methods like <code>testGet<\/code> or <code>testAdd<\/code>, or <code>testSubtract<\/code>. Short method names that don't describe the scenario that they're testing in much detail.<\/p>\n\n<p>What if a <code>get<\/code> method returns different types of value based on the input or a string is passed into a calculator method like <code>add<\/code> or <code>subtract<\/code>?<\/p>\n\n<p>I'd assume that the result of the calculation returns the total, but the test method doesn't say this.<\/p>\n\n<p>I'd rather be overly descriptive and write methods like <code>should_add_two_or_more_numbers_and_return_the_total()<\/code> rather than <code>testAdd<\/code>. It's a lot more readable and easier to see what the intention of the test is, and it's much better to use longer descriptive names when using options like <code>--testdox<\/code> with PHPUnit, which converts the method name into a sentence, which is what I do when running tests in CI pipelines.<\/p>\n\n<p>Something that I've picked up and recommend is to start each test case with the word \"It\" or \"Should\". This gives it a more behavioural feel and puts you in the mindset of what you're testing and not the methods that you're executing.<\/p>\n\n<p>A method like 'testAdd' might make sense within a unit test focusing on a single class and method, but as I usually do outside-in testing - which mostly uses functional and integration tests - this approach works well for me.<\/p>\n\n ",
|
|
"summary": null
|
|
}
|
|
],
|
|
"feeds_item": [
|
|
{
|
|
"imported": "2025-05-11T09:00:51+00:00",
|
|
"guid": null,
|
|
"hash": "e95a217380424b7821a1a9e61d048019",
|
|
"target_type": "feeds_feed",
|
|
"target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
|
|
}
|
|
]
|
|
} |