oliverdavies.uk/content/node.23bff06b-34e8-4f9a-ae67-4405393c874c.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": "1970-01-01T00:33:45+00:00",
            "guid": null,
            "hash": "e95a217380424b7821a1a9e61d048019",
            "target_type": "feeds_feed",
            "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
        }
    ]
}