Test createAsync not working as expected
Im creating test for Register method and I cant mock the createAsync method for some reason
in my controller: var createdUser = await userManager.CreateAsync(appUser, registerDto.Password);
in my test: A.CallTo(() => userManager.CreateAsync(appUser,registerDto.Password)).Returns(IdentityResult.Success);
In the test it is returning identityresult.succeeded, but in controller it returns a bit dfifrent object
18 Replies
not sure why but I needed to pass to CreateAsync(A<AppUser>.,A<string>.) instead of CreateAsync(AppUser, registerDto.password)
Is that actually a useful test?
You’re probably only really testing those mocks
I have no idea, im kinda new to unit testing and form waht I understood I need to check if input data matches output data, and any stuff that isnt mine is better to mock such as createasync or db calls or stuff like that
Personally I’d do that as an integration test, complete with an actual database
The database is yours, don’t mock it
What database engine are you using?
mysql
these are my functions
so if testing stuff like login / register its better to do intergartion test over unit test?
Your tests will have more value for stuff like this if they’re integration test yeah
For standing up MySQL, you can install the server on your machine, or use something like https://dotnet.testcontainers.org/
Integration tests in ASP.NET Core
Learn how integration tests ensure that an app's components function correctly at the infrastructure level, including the database, file system, and network.
does it also apply for everthing that is using database?
if so then whats the points of unit testing if I should be using intertation tests over unit tests
Unit tests are good for standalone things like static methods
Like if you have some complicated string parser, that would be good to unit test
As an aside, mocks are still valuable even in places like integration tests, for services that are truly external and you can’t reasonably test against them
Eg if your app queries a weather service, but calling that API in your tests would be too expensive
Or you need to simulate failure or other conditions
I feel like I got a better idea of tests now, so when it comes to testing api endpoints it would be better to do integration test for 99% of them?
That’s my take yeah
Eventually you’ll get a feel for which kind of test is best for each case
also in this context wouldnt .net libraries count as external stuff?
“External” meaning what you cannot control
So like, I have a Discord bot with a (admittedly pretty meh) test suite
Everything is “real” in my tests except for the calls to the Discord API
Because setting it up for testing is just impractical
im not really familiar with intergration tests and contenerization yet, but if I wanted to check for autheorized user some api endpoint like check all his favorite recipes, should I set up user authentication, pass user to endpoint, do db call, check result without mocking anything?
I would yeah
thanks for help, after finding some tutorial on integration tests I think I more or less understand them now