Ja testuję logikę. To co pokazałeś to wygląda jak zwykły worek na dane, DTO czy ViewModel... takich rzeczy nie testuje. Jak by tam była jakaś logika w tworzeniu obiektu, to bym to przetestował. Guardów typu sprawdzenie czy argument nie jest nullem mimo że to pewna "logika" też nie testuje jednostkowo. Zwłaszcza, że to można zaimplementować w zależności od technologii na kilka sposobów, od ifów, przez kontrakty na specjalnych klasach typu Fail.IfNull() kończąc.
Edytka dodaje: (jeżeli guardy wynikały by z logiki biznesowej i rzucały by odpowiednimi wyjątkami, to przetestował bym je jako corner casy, b były by częscią logiki, a nie częścią specyfikacji języka jak np nullowalność obiektów).
Jak już zostało wspomniane, można to przetestować integracyjnie w miejscu użycia, nie jako przy okazji. A i to niekoniecznie, bo zależnie gdzie by się znajdował, mógłbym też jeśli było by to jakieś DTO czy ViewModel, co najwyżej go w testach integracyjnych tworzyć, żeby wrzucić jako parametr do testowanej metody.
Co bym przetestował, gdzie jest moja granica? Gdy np identifier był w jakiś sposób zmieniany, np jeśli jest nullem albo pustym stringiem to przypisz mu X (nie ważne czy w konstruktorze, czy getterze ta logika by się znalazła, to już inna kwestia gdzie taką logikę umieścić, w konstruktorze czy getterze). To byłby jednocześnie wartościowy test chroniący przed regresją i dziwnymi problemami jak i forma dokumentacji kodu (co testy powinny też robić).