-
-
Save plioi/b15b1a6df8d7c5c0cf51 to your computer and use it in GitHub Desktop.
| namespace ContactList.Core.Domain | |
| { | |
| using System; | |
| public abstract class Entity | |
| { | |
| public Guid Id { get; set; } | |
| } | |
| public class Contact : Entity | |
| { | |
| public string Name { get; set; } | |
| public string Email { get; set; } | |
| public string Phone { get; set; } | |
| } | |
| } |
See https://github.com/fixie/fixie.demo
Keep an eye out for README content comming soon, where I'll point out the highlights.
I generally avoid ReSpawn now. I'd rather force myself to write my tests a little more "defensively" so that I have more confidence that the features will really work against an interesting production database. If I'm testing something like a report query, though, I might have to start the test by deleting one or two tables myself, but I haven't run into that much.
Similarly, I've come to avoid AutoFixture. It's such a time saver at first, but in combination with things like Entity Framework, it results in very unrealistic entities being saved and interacted with. I'd rather take the extra time up front to set things up so that my test database experiences more realistic setup. That "Testing" file tends to grow to have helpers for performing the most common setup tasks. Those helpers will, themselves, Send(...) some message to be handled like Send(new RegisterUser.Command{...}) or Send(new AddContact.Command{...}) and yes, I fill in the properties myself "the hard way" :). If that gets boring, I usually have a small helper or two for including a randomized suffix on a string, or a realistic-looking random phone number, or whatever I really need in the moment. In all of this test setup helper method work, my decisions are specific to the application and emphasize brevity in the tests.
Makes sense! I'll start with this and see what makes sense for us. Thank you!
Hi Patrick! I'm following along your blog on powerful integration testing, and was wondering if you have the whole solution posted somewhere? Also if your strategy has changed much since the writing of that article? Thank you for the post, very interesting read and use of some interesting tools.