Using The DARK ARTS To Write Tests For Blazor Page Declarations

so I had a request on one of my last Blazer testing videos to go through and be able to test something with an example and I wanted to put this content together and the way that I had to approach it is going to involve some techniques that a lot of people aren't really a fan of we're going to have to start using some tools within C that not a lot of people like to lean on but I do think there's a time and a place for them so in this video we're going to be looking at how we can test and look at some different things that have to do with the page Declaration on our Blazer pages and I wanted to say thanks to the person for requesting this and if you yourself are watching this and trying to develop Blazer applications whether it's testing or something else or even if it's unrelated to Blazer and just C related please feel free to ask questions in the comments I'm happy to try and put some content together to help you out all right so what is this technique or this tool that we have within C that not a lot of people like to lean on well it's reflection and I do think that there's a time and a place for reflection I like writing content about using plugins and I use a reflection a lot for that but in this particular case we're going to be using reflection to examine some of the properties that we have within a page so with that said let's jump right over to visual studio and get started all right so on my screen I have the counter Blazer page and this is just one of the pages that comes from the template project when you create a new blazer project with inv Visual Studio we're not going to be focused on all of the content that you see on the screen except for this one thing right at the top which is the at page declaration and the request that I had was what can we do with respect to being able to test this and to be honest I wasn't totally sure what things we had available to us in order to assert and check different things regarding the page declaration and I also hadn't sat there and considered the different reasons why we might want to test this so I thought it was a great request a good exercise for myself and I wanted to share the learnings with all of you so specifically we are going to be looking at this at page declaration and what I found online that was interesting is that this page this whole razor page that we're looking at will get compiled into a class that has attributes that go along with this page declaration and that means if we have something like attributes we can use reflection to examine the class that's created as a result of this Blazer page and that means with reflection and looking up attributes we can go look up different information and assert that it's what we expect I have other videos about testing stuff in asp.net in particular the routes or looking at do comments so I'll link one of those right up here and you can go check that out as well but this is the same type of technique that I used for those types of tests what we're going to be doing is using reflection to examine the type that's created as a result of that Blazer page that I had on the screen so even though the syntax we're looking at is that razor syntax right we have the app page declaration some HTML a code block all of that's going to get turned into a class and that at page declaration becomes an attribute on that class so we'll use reflection we're going to examine the type in this case the page is called counter so we'll have a counter class we're going to pull off that attribute from that type and we're going to see if it matches what we expect is this based case really that valuable maybe not necessarily but let's walk through it and we'll see what we can do afterwards with something a little bit more complex all right so on my screen now I just have the counter page test that we looked at in one of the past videos and I'm going to scroll down to this new test that we have right at the bottom and you'll notice that it's not that complicated and as I'm going to explain it you might be figuring it out on your own so what I'm doing in this particular test is that we're going to be getting the type of the counter page like I had just explained and we're going to ask for the custom attributes this parameter that we pass in is true is just to look for inherited attributes as well I don't think it's totally necessary in this case but I figured why not include it just to make sure we can find the attribute we want and that's going to give us back an array of attributes from there I'm using an xunit assert single method and what that allows us to do is check this array of page attributes that we've just created and look for one that matches this rote attribute I technically don't need this name Alias here that's a bit of a spoiler for what we're going to look at next so this is going to give us if there's only a single attribute a reference to that page route attribute and this test is going to fail if somehow the compiled code actually resulted in having multiple page attributes now I don't even think that's possible so this is really just a sanity check and the whole point of this is just that we're trying to get this reference right here to our page declaration attribute from there there's not a whole lot that we have access to with that attribute but what it does have is a property called template on it and template in this case if I jump back to the page declaration is going to match this text right here so if we want to check what we have access to we can just check to see if that's going to have counter and that's exactly what we're doing here with this assertion so we're asserting that the template is equal to counter so as I mentioned this particular example it's not super interesting the most interesting part is the realization that that page declaration is an attribute and that if we want to test things with attributes we can use reflection to do that and like I mentioned at the beginning in this video people seem to not really like using reflection for different reasons and I totally agree that it can get overused but I don't think this is an overuse of reflection in fact I think it's a really good use of reflection because we're able to examine some of the type information that we otherwise wouldn't be able to see okay so what does a more complex example look like here and what can we do about it well the template that we have in the page declaration doesn't just have to be a constant value for text there can be parameters in that so what might that look like so on my screen now I've created a new page in Blazer and it's called page with parameter and we can see at the top I have the app page declaration and I've changed things slightly so it's not just called the counter page that we had before but it's actually slash page with param another slash and then this syntax here with the curly brace and then the phrase the parameter followed by another closing curly brace and if we look at the bottom of this file I actually do have a parameter it's called the parameter you can see that it's also marked with this attribute called parameter so we have some interesting things going on here the core of the page isn't really that interesting it's just that it's going to have a title and a header and then some text on it that's going to reflect the value of that parameter but we're not totally interested in looking at that right now we can go look at the previous videos I've created to play around with how we test this stuff we're really focused on this part right here so based on what we have access to what what can we and what should we be testing with regards to the page declaration well in my opinion and based on the previous test we were really just looking to see if this matched a static value that was mapped to the name of the page but in this particular case because we have a parameter here something that I thought would be interesting to test is do we have a matching parameter on this page that we want to make sure is declared and aligned with what we have in the page declaration so for example we could check to make sure that if we didn't have this that this would be a problem obviously this code's not compiling here so maybe if that wasn't displayed in some text this code right here might not really be useful you might want to be able to prove that you have a variable that can hold the parameter that's passed in on the page route is that necessary is it required not necessarily but if you wanted to have tests that could check that out for you I think that could be valuable and you might want to consider this in the inverse way so what if you wanted to have this parameter here and you had it declared but you forgot to declare it up at the top here if you wanted to make sure that that was present the test that we're going to look at is going to give us that opportunity so jumping over to the test that we have I haven't actually come up with a good name for it yet but we can get creative and call it something like page declaration matches parameter declaration and I really think that defines what we're going to be looking at here so this particular test is going to mention that we have a parameter that's named the parameter because I'm not that creative with naming things but that's okay the page we're going to try to pull off that attribute just like we did in the other case but the difference here is I'm going to be checking that the template is matching page with param followed by the parameter name and just to be clear this syntax here might look a little bit confusing but that's because we're using string interpolation and because we need to be working with a string that also has curly braces so we use the double curly braces is to escape a curly brace but then we still need a curly brace to embed the parameter name so this part right here from lines 22 till 27 is going to give us the ability to assert that we have a page declaration as we expect so it's really just checking to make sure that this part exists in our page declaration but that's only one part of the test it's very similar to what we had before except I've now moved part of that check or the assertion directly into this lookup here but what about the rest of it what about that parameter that we had that we wanted to check out well in order to get that we can use a similar technique where we get the type of page with parameter and then we ask for all of the properties on it from there we can use xunit with the assert do single the same as we used above except instead of checking for this route information we can actually check to see if the name of the parameter matches the name that we're expecting we declare it up here on line 20 if we do find a matching one we can then take another step that makes make sure that the property with the name we're looking at also has a parameter attribute on it so very similar syntax it's going to look very similar to what we have up top here but we're going to be asking for that parameter name property so this is a property info from reflection we're going to ask for the custom attributes on it and then from there using assert do single this is going to give us a predicate where we can try to step through each attribute and make sure that the attribute type matches parameter attribute and just to be clear about what parameter attribute is if I jump back to the Blazer page that's looking for this right here it might be a little bit confusing but parameter attribute and parameter are really the exact same thing it's just syntactic sugar that you're able to take off the attribute part because it's able to infer that it is in fact an attribute so to summarize the test that we have here the first portion like I mentioned this part is going to be looking at page declaration it's very much like the last test that we looked at so nothing too unique except for that I'm actually checking the name of the page declaration right inside of this assert do single predicate that we have but the interesting part that I added on here is that using reflection we can use another technique to pull the properties off of this page and based on the property that we find matching the name that we're interested in we can then go check to make sure that it has a parameter attribute on it as well so quickly jumping back to the Blazer page we're now proving that this declaration is as we expect and that we have a property that's going to go alongside with this page declaration so this part here the parameter matches this property name as well and that's going to wrap up today's video on testing some Blazer functionality using reflection which isn't something that people like to lean into reflection is super powerful and allows us to look up information on types which is really cool but a lot of the time people see how cool it is and the and they try abusing reflection to do things that they probably shouldn't C is a strongly typed language we should leverage that for what it's worth but I think that there's some interesting opportunities where we can explore type information especially in scenarios like testing when we want to make sure that things or types are configured the way that we expect thank you so much for watching if you have other ideas like I said in the beginning in this video about things you want to see tested or different ideas for videos that you want to see coverage on for C just let me know in the comments and I'm happy to help thanks and we'll see you next time