{"id":5869,"date":"2023-07-17T07:00:26","date_gmt":"2023-07-17T14:00:26","guid":{"rendered":"http:\/\/writeasync.net\/?p=5869"},"modified":"2023-07-15T13:57:12","modified_gmt":"2023-07-15T20:57:12","slug":"stay-com-implementation-classes","status":"publish","type":"post","link":"http:\/\/writeasync.net\/?p=5869","title":{"rendered":"Stay COM: stubs and testing"},"content":{"rendered":"

Previously, we built a Windows Task Scheduler sample application<\/a> using the COM API via WIL. As far as the client code was concerned, COM was a detail encapsulated by the C++ facade we created:<\/p>\n

\r\nvoid run()\r\n{\r\n    auto cleanup = init_com();\r\n    auto service = TaskService::connect();\r\n    auto folder = service.get_root_folder();\r\n    auto task = service.create_task();\r\n    task.set_author(L"Author Name");\r\n    task.set_logon_type(TASK_LOGON_INTERACTIVE_TOKEN);\r\n    task.set_settings(true, std::chrono::minutes(5));\r\n    task.add_time_trigger(L"Trigger1", make_date_time(2005y \/ 1 \/ 1, 12h + 5min), make_date_time(2015y \/ 5 \/ 2, 8h));\r\n    task.add_exec_action(get_executable_path());\r\n    folder.save(task, L"Time Trigger Test Task");\r\n}\r\n<\/pre>\n
Not a COM pointer to be seen here! However, the implementation code has all the gory details:<\/p>\n
\r\n    void Task::set_author(LPCWSTR author)\r\n    {\r\n        wil::com_ptr<IRegistrationInfo> pRegInfo;\r\n        THROW_IF_FAILED_MSG(m_task->get_RegistrationInfo(pRegInfo.put()), "Cannot get identification pointer");\r\n        auto value = wil::make_bstr(author);\r\n        THROW_IF_FAILED_MSG(pRegInfo->put_Author(value.get()), "Cannot put identification info");\r\n    }\r\n<\/pre>\n
These details are unavoidable — they are essential complexity<\/a>. But the problem is that nothing here is testable and therefore, nothing is tested. The entire application thus far is contained in main.cpp<\/code>! To have a chance of testability, we need to break out the components into separate translation units<\/a> and validate them in our unit test project. So, let’s begin.<\/p>\n
The easiest candidate for extraction is the date\/time code. We can simply move it into our static library, splitting declarations into a header and definitions (well, the singular definition) into an implementation file. Now, it is testable:<\/p>\n
\r\nTEST(date_time_test, make)\r\n{\r\n    auto dt = make_date_time(2001y \/ 2 \/ 3, 4h + 5min + 6s);\r\n\r\n    ASSERT_EQ("2001-02-03 04:05:06", std::format("{:%Y-%m-%d %T}", dt));\r\n}\r\n<\/pre>\n
This change was easy: Move DateTime to lib, add test<\/a><\/p>\n
However, that change has nothing to do with COM. It’s more of an exercise in setting up our test\/development cycle, and so far we’re green<\/a>. The next step is to extract one of the COM facade classes (easy enough: Move Task to lib<\/a>) and then comprehensively test it (!!!).<\/p>\n
This is the type of test we would like to write, eventually:<\/p>\n
\r\nTEST(task_test, basic_scenario)\r\n{\r\n    Task task(make_stub_task_definition());\r\n\r\n    task.set_author(L"A. Person");\r\n    task.set_logon_type(TASK_LOGON_SERVICE_ACCOUNT);\r\n    task.set_settings(false, 59min);\r\n    task.add_time_trigger(\r\n        L"Trigger1",\r\n        make_date_time(2020y \/ 10 \/ 20, 15h + 37min + 42s),\r\n        make_date_time(2022y \/ 11 \/ 30, 7h + 6min + 59s));\r\n    task.add_exec_action(L"C:\\\\WINDOWS\\\\System32\\\\notepad.exe");\r\n\r\n    auto expected = L". . . something . . .";\r\n    assert_state(task, expected);\r\n}\r\n<\/pre>\n
But there are clearly several prerequisites to get there from here. Before we dive deep on the end-to-end, let’s start from a more modest position. Maybe we can test just the first thing, set_author<\/code>. Since we’re practicing legacy-style test last development<\/a> here, we can inspect the implementation code to see what we might need. Following the control flow, we would need at least these elements:<\/p>\n