{"_id":"5447ef460319802200fc070d","user":"54471f91beb6320800da6f75","version":{"_id":"54471fc9e12a270800028adf","__v":10,"project":"54471fc9e12a270800028adc","createdAt":"2014-10-22T03:08:57.750Z","releaseDate":"2014-10-22T03:08:57.750Z","categories":["54471fc9e12a270800028ae0","5447b9e7b96a63140077d747","5447be130319802200fc0620","5447ed118d7af31a00dd411c","5447ed230319802200fc0702","5448524c4544c30800241f41","544854504544c30800241f4d","544854af4544c30800241f50","544854e74544c30800241f51","54485557c1b42e08005b82bf"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1.0"},"category":{"_id":"5447ed118d7af31a00dd411c","__v":5,"pages":["54485515c1b42e08005b82bd","5447ed4d8d7af31a00dd411d","5447ef460319802200fc070d","54485571c1b42e08005b82c1","54af53eb0cf42a0b001d5b73"],"project":"54471fc9e12a270800028adc","version":"54471fc9e12a270800028adf","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2014-10-22T17:44:49.648Z","from_sync":false,"order":3,"slug":"assertions","title":"Assertions"},"is_link":false,"__v":5,"project":"54471fc9e12a270800028adc","updates":["545ead257e32310e00f400e4"],"next":{"pages":[],"description":""},"createdAt":"2014-10-22T17:54:14.500Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"basic_auth":false,"results":{"codes":[]},"try":true,"auth":"never","params":[],"url":""},"isReference":false,"order":2,"body":"[ShouldLookLike()](http://specsfor.readme.io/v1.0/docs/additional-should-assertions) compares two complex objects, but what if you only want to compare just some of the properties of an object, instead of all?  \n\nSuppose you have an Account model but the value of the AccountNumber property is a random integer and its assignment is beyond your control.  You cannot assert its value because the correct value isn't readily known.  A spec like this will fail:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"[Test]\\npublic void then_returns_the_expected_model()\\n{\\n     _account.ShouldLookLike(new Customer\\n     {\\n       \\t\\t//AccountNumber = ???\\n          CustomerName = \\\"Atticus Finch\\\",\\n          Balance = 5042.61\\n     });\\n}\",\n      \"language\": \"csharp\"\n    }\n  ]\n}\n[/block]\nThe _account object has a value for its AccountNumber property, but the Customer that it is being compared to does not have that property initialized, so it will have its default value.  That means the two objects will not *look *the same, as they will differ by their AccountNumber properties. \n\nThere's an overload of ShouldLookLike that accepts a lambda expression as input.  When you pass in a lambda expression that creates a new instance of the object you wish to compare to, SpecsFor will only validate the properties that you initialize.  All other properties are ignored.  So, you can ignore the AccountNumber property like so:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"[Test]\\npublic void then_returns_the_expected_model()\\n{\\n     _account.ShouldLookLike(() => new Customer\\n     {\\n       \\t\\t//AccountNumber = ? //Ignore!\\n          CustomerName = \\\"Atticus Finch\\\",\\n          Balance = 5042.61\\n     });\\n}\",\n      \"language\": \"csharp\"\n    }\n  ]\n}\n[/block]\nAs long as the _account object's CustomerName and Balance properties match, the spec will pass.  All other properties are ignored.\n\nThere are some limitations to the types of expressions that you can use with this overload of ShouldLookLike.  To get around those limitations, SpecsFor also provides the ShouldLookLikePartial method.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"ShouldLookLikePartial\"\n}\n[/block]\n\n[block:callout]\n{\n  \"type\": \"warning\",\n  \"title\": \"Be careful!\",\n  \"body\": \"Whenever possible, use the strongly-typed partial matching that's described above.  Anonymous objects are not refactor-friendly, and your specs may break at test time if properties are renamed or removed.\"\n}\n[/block]\nShouldLookLikePartial accepts an anonymous object as input.  You can exclude the AccountNumber property from comparison by using ShouldLookLikePartial() and not including the AccountNumber property in the anonymous object.\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"[Test]\\npublic void then_returns_the_expected_model()\\n{\\n     _account.ShouldLookLikePartial(new\\n     {\\n          CustomerName = \\\"Atticus Finch\\\",\\n          Balance = 5042.61\\n     });\\n}\",\n      \"language\": \"csharp\"\n    }\n  ]\n}\n[/block]\nAs long as the _account object has the expected CustomerName and Balance, this spec will pass.\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"Did you know?\",\n  \"body\": \"Both ShouldLookLike and ShouldLookLikePartial can work with complex, nested objects, including arrays and collections.  You are not limited to comparing objects with simple value types.\"\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Partial Matching with Looks.Like\"\n}\n[/block]\n\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"This functionality is only available in SpecsFor 4.3.0+\"\n}\n[/block]\nWhen setting up expectations or verifying a mock's behavior, you may not always care about every property on objects that are passed to your mock object's methods.  Moq's It.Is<T>() method will allow you to check specific conditions, but checking multiple properties with it quickly becomes tedious:\n\nInstead, you can use Looks.Like to check that a parameter *looks* like a given object.  If you only care about specific properties, you can use the overload of Looks.Like that accepts a lambda expression, like so:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"\\t\\tpublic class when_verifying_with_a_partial_object : SpecsFor<object>\\n\\t\\t{\\n\\t\\t\\t[Test]\\n\\t\\t\\tpublic void then_it_verifies_correctly_if_the_object_matches_the_specified_properties()\\n\\t\\t\\t{\\n\\t\\t\\t\\tvar myCar = new TrainCar {Name = \\\"Simple Car\\\", MaxPassengers = 100, YearBuilt = 2014};\\n\\n\\t\\t\\t\\tGetMockFor<ITrainYard>().Object\\n\\t\\t\\t\\t\\t.StoreCar(myCar);\\n\\n\\t\\t\\t\\tGetMockFor<ITrainYard>()\\n\\t\\t\\t\\t\\t.Verify(x => x.StoreCar(Looks.Like(() => new TrainCar{YearBuilt = 2014})));\\n\\t\\t\\t}\\n\\t\\t}\",\n      \"language\": \"csharp\"\n    }\n  ]\n}\n[/block]\nOnly the properties that you initialize in your lambda expression will be validated.  Everything else will be ignored.","excerpt":"","slug":"shouldlooklike-and-lookslike-helpers","type":"basic","title":"Partial matching: 'ShouldLookLike' and 'LooksLike'"}

Partial matching: 'ShouldLookLike' and 'LooksLike'


[ShouldLookLike()](http://specsfor.readme.io/v1.0/docs/additional-should-assertions) compares two complex objects, but what if you only want to compare just some of the properties of an object, instead of all? Suppose you have an Account model but the value of the AccountNumber property is a random integer and its assignment is beyond your control. You cannot assert its value because the correct value isn't readily known. A spec like this will fail: [block:code] { "codes": [ { "code": "[Test]\npublic void then_returns_the_expected_model()\n{\n _account.ShouldLookLike(new Customer\n {\n \t\t//AccountNumber = ???\n CustomerName = \"Atticus Finch\",\n Balance = 5042.61\n });\n}", "language": "csharp" } ] } [/block] The _account object has a value for its AccountNumber property, but the Customer that it is being compared to does not have that property initialized, so it will have its default value. That means the two objects will not *look *the same, as they will differ by their AccountNumber properties. There's an overload of ShouldLookLike that accepts a lambda expression as input. When you pass in a lambda expression that creates a new instance of the object you wish to compare to, SpecsFor will only validate the properties that you initialize. All other properties are ignored. So, you can ignore the AccountNumber property like so: [block:code] { "codes": [ { "code": "[Test]\npublic void then_returns_the_expected_model()\n{\n _account.ShouldLookLike(() => new Customer\n {\n \t\t//AccountNumber = ? //Ignore!\n CustomerName = \"Atticus Finch\",\n Balance = 5042.61\n });\n}", "language": "csharp" } ] } [/block] As long as the _account object's CustomerName and Balance properties match, the spec will pass. All other properties are ignored. There are some limitations to the types of expressions that you can use with this overload of ShouldLookLike. To get around those limitations, SpecsFor also provides the ShouldLookLikePartial method. [block:api-header] { "type": "basic", "title": "ShouldLookLikePartial" } [/block] [block:callout] { "type": "warning", "title": "Be careful!", "body": "Whenever possible, use the strongly-typed partial matching that's described above. Anonymous objects are not refactor-friendly, and your specs may break at test time if properties are renamed or removed." } [/block] ShouldLookLikePartial accepts an anonymous object as input. You can exclude the AccountNumber property from comparison by using ShouldLookLikePartial() and not including the AccountNumber property in the anonymous object. [block:code] { "codes": [ { "code": "[Test]\npublic void then_returns_the_expected_model()\n{\n _account.ShouldLookLikePartial(new\n {\n CustomerName = \"Atticus Finch\",\n Balance = 5042.61\n });\n}", "language": "csharp" } ] } [/block] As long as the _account object has the expected CustomerName and Balance, this spec will pass. [block:callout] { "type": "info", "title": "Did you know?", "body": "Both ShouldLookLike and ShouldLookLikePartial can work with complex, nested objects, including arrays and collections. You are not limited to comparing objects with simple value types." } [/block] [block:api-header] { "type": "basic", "title": "Partial Matching with Looks.Like" } [/block] [block:callout] { "type": "info", "title": "This functionality is only available in SpecsFor 4.3.0+" } [/block] When setting up expectations or verifying a mock's behavior, you may not always care about every property on objects that are passed to your mock object's methods. Moq's It.Is<T>() method will allow you to check specific conditions, but checking multiple properties with it quickly becomes tedious: Instead, you can use Looks.Like to check that a parameter *looks* like a given object. If you only care about specific properties, you can use the overload of Looks.Like that accepts a lambda expression, like so: [block:code] { "codes": [ { "code": "\t\tpublic class when_verifying_with_a_partial_object : SpecsFor<object>\n\t\t{\n\t\t\t[Test]\n\t\t\tpublic void then_it_verifies_correctly_if_the_object_matches_the_specified_properties()\n\t\t\t{\n\t\t\t\tvar myCar = new TrainCar {Name = \"Simple Car\", MaxPassengers = 100, YearBuilt = 2014};\n\n\t\t\t\tGetMockFor<ITrainYard>().Object\n\t\t\t\t\t.StoreCar(myCar);\n\n\t\t\t\tGetMockFor<ITrainYard>()\n\t\t\t\t\t.Verify(x => x.StoreCar(Looks.Like(() => new TrainCar{YearBuilt = 2014})));\n\t\t\t}\n\t\t}", "language": "csharp" } ] } [/block] Only the properties that you initialize in your lambda expression will be validated. Everything else will be ignored.