[Music] welcome to our first episode of inside the ferkin where we tackle consulting uh topics one at a time in a much easier and shorter uh concept nice so [Laughter] yeah so inside the curtain those are smaller barrels than your normal sized barrel or cask there are 11 gallons so we're gonna try to do these in a shorter bite size manner where people can really look at it and learn faster with less commitment right less time commitment because lives get busy right yeah yeah totally yeah i'm gonna hold you to this 5-10 minute mark and we'll see we'll see how it goes all right perfect so what are we doing today we're doing uh scripting and other scripting patterns yeah yeah so we're essentially gonna continue from where we left off last time and really kind of provide some opportunities for for different strategies for uh people to uh utilize different script includes so i'm gonna we'll just jump right in so this is a little bit different because i already did most of the work oh the magic oven i love it yeah so for those that don't know um again we're we're following this like uh great article um for uh by travis called interface design patterns for script includes and we really talked a lot about uh class patterns last time about how it's the the default one you could do a lot with it and so today we're going to move on towards the function pattern and essentially [Music] what the function pattern is is essentially just creating a function so rather than anything in here other than uh rather than all of the boilerplate that's there before you just create one function and it could pat you could pass in some variables and then it does some things inside of it and so some of the pros of that is it's very simple right like it's just one function you don't have to anyone that knows javascript will know what if that function looks like you can do a lot with it because it's just vanilla javascript in here obviously with you could pass around functions or things like that and what's also nice is these nested nested functions are are private so you truly no one can just call your function from here they would have to call just the the upper function so so this is kind of nice a nice way to handle script includes there are some downsides to this though organizationally like imagine if every script included was one function john oh my gosh trying to keep track of that oh man yeah it would be rough um the other downside is you can't easily test nested functions so like we did want to make this so it's easier to unit test that was one of the premises that we had here so it's kind of defeats some of that purpose if we can't really test it the good thing is is servicenow actually has done that and i was a terrible uh drag and drop so if you wanted to ever look at a code search it is an example of uh one that servicenow has out of the box so here you can see here it's just you know one function right so it is used in servicenow's production instances so don't think that if you did use this you're doing something terribly wrong sure cool so let's kind of hop into what this function is doing so this function looks very similar rather than setting something to active john i changed it to locking them out so essentially what this function does is just calls lock out a user based on their society so within lockout you have a function um that's called lockout locked locked out user to check if they're locked out and so we have some print statements here and then if they aren't locked out then go and lock them out else return this random variable three three i think we saw that last yeah um so so that's that's pretty much all this function is doing and um so what we kind of want to go to is our handy-dandy uh atf's and so inside our hand our atf so we created a function pattern unit test and this one looks a little bit different as well so essentially what we have is we have some variables here so we're passing in whether someone's locked in or locked out a first name and email so we can easily see it and so this is our test data we have one user that is locked out and i just named it locked out so we can easily see it and one that isn't and then for the test steps we create a user since now we don't want to be messing with data that already exists so we create this user we then the magic happens in here we we run this test so we're essentially pulling the step data from the created user above so we want to use the sys id of that user we just created and this locked out and then essentially saying if the user is locked out so if we are locked out we want to check if they um check how many updates are on their record and and i'll go into why we do that we then run that we we run this script so this is what um the function pattern here looks like and note the difference there's no new right right yeah so it does look different and then we then check um whether or not they they were updated and so the reason why we're doing it this way is for this function to run we can't test all of the nested functions so um uh and so what we want to check is how how often is this thing modified so if the user is already locked out we don't want to actually modify their record right that would be inefficient so what we're doing here is saying if the user we first check how what the mod count is we run the function and then we check what the mod count is after we ran that function and then we check if they're equal because remember i can't test functions within the function i can only test the highest level function and this highest level function returns you know um you know either the update or three right so that's how we're essentially doing it and then very similarly here this one's a little bit different we check the mod count we then run the function and then we check if the mod count increased by one right did we actually update the the ticket and are they now locked out is uh am i reading that right on 27 it says it is that supposed to be if or is that an f i can't tell oh so that's it so that's that's jasmine syntax so for for your unit test here you describe is like the the high level sweep that's right the actual test is yet so okay so let's go and run this um and we'll actually debug it and i put some break points here um again shout out to san diego really really awesome uh release great yep so what's nice here is now my my script is stopped it did execute one right and so let's check if we get a new user and here's our new user it's locked out there we go we're locked out there's zero updates on it so we step over so now we have run the function right so now that the function is run we want to check what our data looks like still locked out and zero updates so we're thinking that our first use case was the locked out user is gonna uh is gonna be okay so now we roll back that data and that should pass awesome and so now uh we check again and we see now that user is gone so the data was rolled back now we're looking at the test user too that isn't locked out right now no updates we step over we now have run our function and so we look at this again and we'll see now that they're locked out and there's an update so we know that this will pass as well so and now it's going to roll back and now we we have working tests so now we know that our function essentially is doing what it's supposed to and granted it's not the perfect unit test it's a little bit more of like an integration test um but you can see here you know that this test passed that we that we had for it and we can we can check the same thing here as well that you know this this test passed so that is the function pattern in a nutshell nice i know i like it um i'm not sure that i'd ever like i'm trying to think of from the portal side if i'd ever use something like this just because it does get a little uh messy when you have single use script includes because normally under for portal i'm building a um a heavy lifter right that does a lot of work um and i i just don't see how i can get away with you know then i'd be calling multiple script includes where i'm trying to get away from that right i'm trying to centralize but uh yeah totally yeah i think i think the function one is really like you have one some one-off function it doesn't belong in some utils somewhere like right just create a function pattern yeah so that's that would be the route that i would go um we'll talk about other patterns in our next sessions about namespace and actually improving on this so sure so we'll stay tuned for that one nice no i i like that um yeah no this was great uh i like this shorter format yeah yeah because now because now someone can just grab it and look at it and be done real quick you know and not have to spend an hour listening to us jibber jabber yeah totally no i i agree so i hope i hope people find it useful we'll go over future patterns in the next one and hopefully this helps somebody in in designing the architecture and then being able to test it with with atf's no i agree um i like going through the atf's because i don't i don't ever use those but it's it's interesting how far they've come because i remember like way back atf's were really tricky to get them working and there was a lot of issues so i'm glad to see that they're making progress with the updates on that yeah i think the break points and the debug definitely actually bring it to the next level before it was like you'd have to rush to figure it out add a bunch of sleeps in there and it was just really painful now like now we're actually in a in a really good state with running atf for server-side unit testing so yeah yeah definitely oh that's great well great um this is this yeah if you like this content let us know subscribe yeah reach out to us and we'll keep doing some so yeah we're always looking for new topics yeah yeah if you like our furkin topics you know we'll continue to do it yes the topics all right thanks everyone see ya