Thanks for caring about us 😅 Great one as usual 👍😃 In our projects we usually use integration tests, in a similar way that you demonstrated. We also use LightBDD + pattern given/when/then and write tests in a story like way, so anyone can read and understand them.
I like that you used web app factory. This seems to be a fantastic tool to have in the bag. Would love to see more on how you use it for more than quick demo tests.
At 1:20 or so you refer to your new favorite toy for developing APIs. Can you say more about it (what the name is, what it does, why it is better than Postman)? Thanks! - jesse
Thank you Shawn, I was wondering how to set up Integration tests inside the solution (I generally use an external tool), and it was really illuminating for me
I don't think that IClassFixture works in this way: from the xUnit Documentation, this creates a single object which is then shared with all test in a class - and it's the test class that has a new instance for each test, with the shared fixture being passed to it. I.E it is only created once, and so does not provide a clean object. To achieve that, you would need to use constructor / dispose in the test class to have a new object instance created. IClassFixture is intended to avoid expensive initialisations.
While what’s shown here is a great start, make sure to get very familiar with mocking and ways of producing deterministic (yet random) data to use for assertions etc. Shaun’s going around this with very simple examples and you’re likely going to face much more complexity on larger projects. I’m a big fan of terse tests and being true to the SOLIS principles, leading to small units of code, but not all teams are aligned on this topic (or as experienced).
(it's *Shawn* btw) I agree with this. My examples are simple and building up for real-world is more complex. But, again, this type of APIs aren't Unit tests. These should be integration tests (smaller set than Unit tests). I wouldn't necessarily need every test/permutation tested as Unit Tests should test those. This is about testing your units working together..
@@swildermuth people will do by pass code just to make 100% not to test foreign key , output and input . Unit test maybe good before real implementation but once back end and front end good to go , integration test is the way to go . Most sample unit test a + b , most in real life got formula so on , so we need to make sure it work first in first out .
Thanks Shawn for a succinct explanation of the basics.
I appreciate that.
Thanks for caring about us 😅 Great one as usual 👍😃 In our projects we usually use integration tests, in a similar way that you demonstrated. We also use LightBDD + pattern given/when/then and write tests in a story like way, so anyone can read and understand them.
Shawn Wildermuth “cares about me?!” Awww. Lol!
Wow, this video is amazing!😲 Your programming skills are truly impressive.
I like that you used web app factory. This seems to be a fantastic tool to have in the bag. Would love to see more on how you use it for more than quick demo tests.
At 1:20 or so you refer to your new favorite toy for developing APIs. Can you say more about it (what the name is, what it does, why it is better than Postman)? Thanks! - jesse
Thank you Shawn, I was wondering how to set up Integration tests inside the solution (I generally use an external tool), and it was really illuminating for
me
Informative and straight to the point. Will there be any session recordings of kcdc event 2023 available anywhere?
Unfortunately, it wasn't recorded.
I don't think that IClassFixture works in this way: from the xUnit Documentation, this creates a single object which is then shared with all test in a class - and it's the test class that has a new instance for each test, with the shared fixture being passed to it. I.E it is only created once, and so does not provide a clean object. To achieve that, you would need to use constructor / dispose in the test class to have a new object instance created. IClassFixture is intended to avoid expensive initialisations.
While what’s shown here is a great start, make sure to get very familiar with mocking and ways of producing deterministic (yet random) data to use for assertions etc.
Shaun’s going around this with very simple examples and you’re likely going to face much more complexity on larger projects. I’m a big fan of terse tests and being true to the SOLIS principles, leading to small units of code, but not all teams are aligned on this topic (or as experienced).
(it's *Shawn* btw) I agree with this. My examples are simple and building up for real-world is more complex. But, again, this type of APIs aren't Unit tests. These should be integration tests (smaller set than Unit tests). I wouldn't necessarily need every test/permutation tested as Unit Tests should test those. This is about testing your units working together..
my opinion no unit test junk , integeration test
I don't actually agree, I think there is value in unit tests, but trying to unit test for code coverage is a waste of time. IMHO
@@swildermuth people will do by pass code just to make 100% not to test foreign key , output and input . Unit test maybe good before real implementation but once back end and front end good to go , integration test is the way to go . Most sample unit test a + b , most in real life got formula so on , so we need to make sure it work first in first out .