How to Write Blazor Unit Tests With bUnit and xUnit

[@DevLeader]

Thanks for your support! Check out my FREE weekly newsletter: subscribe.devleader.ca

[@agan_dev]

thank you so much

[@DevLeader]

I'm glad you found it helpful! 💪💪

[@golljhjkahsdah2817]

awesome.

[@DevLeader]

Glad you like it!

[@2u1u]

A good introduction to testing rendered elements. Thank you! Can declarations like the @page route be tested? I guess the same goes for @inject services.

[@DevLeader]

Thanks for the comment! Just to check my understanding of your question: - You would like to ensure that the razor page route can be navigated to based on what's in the @page declaration? - For the @inject part, what would you like to actually be asserting? The presence of this, or that the service is injected, or something else? If you can clarify a bit (maybe explain why as well) then I can see if I can whip something up 🙂 Thanks!

[@2u1u]

@@DevLeader apologies, for the @page declaration, I was curious o If the test is capable of checking the value being set and possibly asserting the route is of a particular value. For the @inject, I guess I was thinking if oninitialized calls the injected service how bunit handles this and if we'd need to mock said service.

[@DevLeader]

@@2u1u Nothing to be sorry about! I do very much appreciate that you're asking questions and being curious. It's on my end for not understanding, so I just wanted to make sure I had clarity so I could answer more effectively 🙂 Let me see if there's a good way to do this route check. I've done route configuration tests in asp.net (discover all of them, check they're configured properly, etc...) but this feels like a different perspective on a similar type of thing. I'll make a note to cover it in some capacity! For @inject, if you fail to have a matching service registered in DI bUnit will blow up when it tries. I believe bUnit is simply creating the component via DI, so if the dependency it needs isn't present then it will fail to create it right in the test. I just realized we were discussing these on the *first* video in this series 🙂 The second one comes out on Monday and my newsletter subscribers received early access to it this morning. It actually covers the @inject scenario sufficiently, in my opinion. The newsletter software is kinda tricky, but if you message me on Instagram with your email I can send you the issue if you'd like!

[@blacknwhite5451]

Thanks, this will be useful getting started. However I would recommend not setting internal values (with the exception of parameters that are required) and instead manipulating the gui. This more accurately tests how the user will interact with the page. Setting the counter to 5, is not testing the funtion that increments the counter, or the gui button to see that it calls that function correctly. So it has very limited value.

[@DevLeader]

This is conceptually about setting state so that you can test given scenarios. If I need a value to be at 10,000 before I can test a scenario, I'm not going to loop 10,000 times to achieve that. There are always going to be scenarios where this is more valuable or less valuable -- it's context dependent.

[@niteshsetin]

One more question: where should the bunit project reside. Does it have any security implications. Can we use it for our internal application in the company.

[@DevLeader]

I personally create my test projects in the same solution as my code that's being tested. The test binaries are just things you don't ship (it's bloat for anything in production). For security implications... There's nothing inherently insecure with bUnit or test projects. However, that doesn't mean putting credentials directly into your tests, for example. I like to imagine if where my tests are running gets compromised then someone isn't walking away with all of my secrets as well. Just like on a production server, you likely are not keeping secrets in plain text, for example. As for using it for an internal application in the company: Yes, I'd absolutely say so. Now a full disclaimer: I can't speak for ANY third party code and sign off on it 🙂 if your company does security and compliance audits, let them review it. But personally I'd see no reason at all to be worried about bUnit.

[@niteshsetin]

@@DevLeader great 😃, thank you for providing in depth detail . It seems that will let the security team to just verify it once.

[@DevLeader]

@@niteshsetin that would be my take I think 😉 get the nod of approval

[@niteshsetin]

Question : why do we need unit testing for blazor frontend only, I understand that backend apis project we can do unit test. But i couldn't understand why we need to write code for ui testing,isnt ui testing has to be manually done.what are we testing when we write those test cases for UI specifically and again if i have complex ui like table where i am testing functionality like export data to csv file or edit the inline cell of tables, isn't it a complex task?

[@DevLeader]

This is a *really* good question, so thanks for asking it! I have a general answer to start with: To build confidence in delivering changes. My goals in software engineering are to be able to ship value to customers as rapidly as possible but without aggressively decelerating over time. That is, sacrifice any other investment so it becomes so difficult to ship software quickly. From my professional experience: any manual testing as part of regression testing absolutely does not scale and will grind teams to a halt. Yes, manual testing for usability and exploration is great. But if you ever plan on repeating that - automate it. Humans are far more useful at test strategy and being a user proxy than just clicking through buttons. But your next point about complicated scenarios - *ESPECIALLY* for stuff like this we should think about how to write code that can be tested via automation. At some point, unit tests might not be the right tool - but doing some other type of functional test could be very valid. At the end of the day, it's all about having automatic regression coverage so you can keep delivering changes with confidence. And ideally, you're picking solutions for that coverage that don't slow you down to maintain. I hope that helps explain my perspective!

[@niteshsetin]

@@DevLeader I do see that in organisation although we have automated testing,it still goes to manual testing via QA and then it goes to UAT which is again by humans and they need to do regression testing since they don't want anything breaking up in production. Aren't this doubling effort at each level. What's the catch here?

[@DevLeader]

@@niteshsetin I mean - if your organization is using humans to do repeated regression testing on *anything* that's something I would (personally 🙂) be advocating to move away from. So short answer: Yes, it's entirely duplicated effort. Longer answer: Are the tests duplicating the effort, or are the humans manually exercising what you could be trying to automate duplicating the effort 🙂 I realize it's not trivial to just change an entire organization (I lived this exact thing for 8 years at a company that I had significant technical influence at) and it was still not fully changed. But my honest opinion is that using humans to regression test *anything* should have focus to move towards automation. Humans are not as effective as machines for repetition 🙂 humans, I think, are better served being creative to think about what and how to test though.

[@niteshsetin]

@@DevLeader on the point, great explanation,I loved it and yes I understand now your point as well. I am gonna sit down with some of our technical managers and see how they want the things to go on.and now I have some points from here as well to argue

[@niteshsetin]

I hope at some point microsoft will release official testing tool for blazor as well.