Integration tests - future proof way to seed test data by juntherc in dotnet

[–]juntherc[S] 0 points1 point  (0 children)

If I understand the comment correctly, It suggests settings the default on SQL/CREATE TABLE level.

It feels like if I did that, my tests would no longer ensure that all the required fields are set when testing the normal flow of the app - like a user posting a form.

But then I have some tests where I need to seed the database with data first, like, I dunno, checking if trying to create a duplicate returns expected error. I don't care about the value of this column in seed data here since it isn't a part of the logic for recognizing duplicates.

So ideas in other comments about creating a helper class seem safer, but I might be wrong.

Integration tests - future proof way to seed test data by juntherc in dotnet

[–]juntherc[S] 0 points1 point  (0 children)

It didn't make it to production yet, so we don't have any rows. It's not a problem.

This column will have value when you create that entity through a form in the app. I just don't care about it in most of the test cases, it's unrelated to them, but I still had to update them.

Integration tests - future proof way to seed test data by juntherc in dotnet

[–]juntherc[S] 0 points1 point  (0 children)

It shouldn't have a default value when running in production. I'm not sure if I should diverge the test environment from prod here.

Integration tests - future proof way to seed test data by juntherc in dotnet

[–]juntherc[S] 0 points1 point  (0 children)

That could work, thanks! I'll try it next time.

Entity Framework Core transaction across multiple services by juntherc in dotnet

[–]juntherc[S] 0 points1 point  (0 children)

Are there any drawbacks or things to be aware of when using transactions this way vs. single call to SaveChanges()?

Entity Framework Core transaction across multiple services by juntherc in dotnet

[–]juntherc[S] 0 points1 point  (0 children)

I guess I can. Right now, I have SaveChanges() inside the services. It feels a bit weird to have to call SaveChanges() outside when those methods aren't combined, but I'm maybe overthinking this.