 Welcome everyone. Let's start. We might need some more time so we may try to visit as much as possible. This is generally very good for the workshop and the conversation. We just got this activity so I will try this visit. So giving you the brief. So this should be the outline for the session. So I will go through the environment which I am using for the demonstration. Then we will again go back to the concepts of Trinity and Biredi. I am sure this is a lot to do but this has already been practiced on the server side most often. Then we will take one domain problem that would be from the real world. It would be the actual problem which we will start coding. Then we will try to come up with the high level stories. And we will start one story by story in the demonstration. And then there will be some slots for the sessions. So the main goal is not to achieve the domain problem which we are considering. The main goal is to understand how we can write clean and testable code in JavaScript using the Trinity and Biredi concepts. So I will come back to the development environment once we go through these couple of slides quickly. So the concepts, all those it is a refactoring philosophy that mostly uses continuity. So when you start new feature or improvements, you write a test first. Make sure it is spinning. That is where we know it is spinning for the right reason. Connect it right to production code to pass that test. And see if there are any improvements. The aspects that this practice has, it will always force your design to keep it simple. And you avoid any wastage that you will be coding upfront. That is the active principle. And it is very important. Whenever you do unit testing, there might not be surrounding modules present. So you need to take it at that time. The benefits, design becomes more clearer, clearer. You always get the testable code. And the focus is only on what is important. So this will keep you focused on what you need to implement. And it will not distract with the other features, whatever coming down the line. Let us jump to the Biredi. By the way, Biredi is already established. Well, it is just an extension. But inside the unit was more depth-centric. Where the Biredi is more driven by the business or business value. So it's like, okay, the problem with unit testing was from where to start. What's the starting point? And Biredi answers that. So it's like, okay, let's take one behavior, one feature at a time. Code that first. And once that feature is coded, then that will drive your unit. Some of the aspects, while giving the name for the particular test, it will make the sentence. And that sentence should be making sense to the stakeholder business, guys. So we are thinking from the customer user perspective. Benefits, again, it could be clear understanding about the software behavior. So that will answer your question like, why should I create that particular code? But that's the behavior we want to support. And that's the need of that particular code. It will help you to give the starting points. And it encourages more collaboration between the stakeholders, BAS, US, clusters, all. So all are on the same page. Let's support this further exercise. We'll be using domain problem, which is Hitmap. Which is commonly used in the financial sectors. But it's just the concept of representing the data. So it's not limited to the financial can use anywhere. To quickly give you the demonstration or the explain the concept of Hitmap. If I show this representation taken from one of the real websites, can you guess what are the top four gainers from this representation? So it's not important who are the four gainers, the process that you need. So actually you've got each functional asset wise, instrument wise. And you compare who has the highest percent change. The thing is, whenever we want to represent some of the things very exciting way, if we make use of some visual aspect, it will have much better subjects. Try to solve same question from this representation. Where the green says it's positive, where it's negative. And there are shades. So the darker the shade, the more the changes. So if I ask you the same question, what are the four gainers from this representation? You're probably able to answer in a maybe taking half time. So that's the Hitmap. So it is a pictorical representation of data. And the change or the value we want to depict is depicted in the shade of the color. And that's what we want to achieve in this exercise. And this is a real-time application or real-time example where the data will push from the server. So whenever in the exchange there is a change in the price for the particular instrument, that will be pushed to the client. And the Hitmap will be updated in real-time. There are some animations to show the particular instrument's price it changed. So it's a bouncing effect. Let's see if we are able to crack all the three stories, we'll be able to see the bouncing effect as well. This is another version of Hitmap which is taken from my real project. So let's quickly identify stories which will run throughout the exercise. In any cases, what could be the stories if we understood the requirements clearly. The third rule for the stories, it has to be marketable. When I say it has to be marketable, it means once a developer done with the story, once development, it has to be a showcaseable. It means it should have some value that customer can see in that. So it has to be always a customer focused. So it has to be marketable. Okay, let's... I have broken down the requirement of the stories. So first story is, as a trader, and this is we are developing for, let's say retail, where retail users like us where we'll go visit the site and see the Hitmap. So as a trader, when I load the Hitmap application, then I want to see the instruments. So that I'll see, I'll get the picture of the market. I'll see all the instruments together, the benefit. Okay, so yeah, that's a nice way to start. Just getting all the instrument details, snapshot and showing on the screen. Second story is, as a trader, I want to see price change updating in real time. So on that, next story we'll add the... We'll start to listen, update messages from the server and we update the change on the Hitmap. And the third story is, as a trader, I should be able to see instrument performance visually. So whatever change we are getting, we'll convert that into the color code and we'll apply that color code to the instrument type. And that's the third story and the benefit is so that the trader will get better overview of the market very quickly. Okay, so this is the story one in more detail. So this scenario is, when a trader starts the application, you will see the instrument with details, instrument symbol, name and price percentage. So now let's jump to the eclipse. We start the... I'm afraid I may not be able to increase the font for the script explorer. So let's go back to the slide which was the environment which we skipped. So I'm using the eclipse ID for JavaScript web developers. I have pre-installed the JT plugin. It's available in Marketplace. It's run JT and plugin. For this exercise, the focus is on front-end development. So we'll be not focusing more on backend side so that I got the ready backend stuff which is called streamer.jar which I have started on 8081. The backend is the implementation of web socket. So that I'll receive the push update methods from the server. Okay, let's go back to the eclipse. Now for convenience, I moved all the necessary folders in web app so that I can easily map my application context to web app. As you notice, the source folder is empty and that's what we want to populate using the test. So I got the couple of infrastructure ready. Inside the test, you will see acceptance integration unit. So acceptance test will contain all the behavior related test, acceptance test. Now there are various approaches of acceptance test. The approach that I'll be using here is that we'll skip the UI layer and the backend layer purposefully. And I'm able to do that because there are lots of exciting frameworks. One of them is knockout. So knockout say if you cooperate your model properly, don't worry about UI. It wouldn't be reflected accordingly. But we can't rely on wiring so that's why we need to write the integration test as well. And of course unit test which would be evolving the technical design mode in more detail. So inside the acceptance test, I got sample test written. This is the very simple test written in Jasmine. So describe the first line is the test suite, the name of the test suite. So it's a let's say Jasmine. Each test starts with a keyword with function. And the first parameter is the description or the name, the sentence of your test. It doesn't give you the mechanism of given, when, then, log. But for starting it's very helpful. But as you mature with or understand it more clearly, you'll see that's unnecessary. So this is some variable I have set. Then this is the matcher or verification. Expect your code to be a lot simpler. How to run it? So I already got the infrastructure in my Eclipse. So inside libraries, I got the Jasmine code. The easiest way to get Jasmine integrated in your workspace is clone the Jasmine project from GitHub. And just paste the dependencies here. It also gives you a runner. So I have just copy paste the runner as it is. It has created two sections. In the specs section, we'll be adding the target test. And in the source code, we'll be adding the production code files. To run it, it's very easy. Just open this into the web browser. And it would say once spread is ready. So that's the environment. That's the Jasmine infrastructure we've got. We'll be using that. So let's, without wasting too much time, let's jump to the first test. So under Hitmap, I'm creating a new file. Let's say HitmapSpec. I'll copy the sample file. Save some time. I have also got some of the cheat code present. So that for the production code, we might do some copy paste to save some time. So let's rename the test. Let's say HitmapSpecs. I don't know what would be here. So the first story says it displays instruments on application load. So that's my first scenario in actual. So it displays all the instruments with basic details when application loads. So whenever we say TDD or PDD, it's not, or when we follow the agile practices, it's not that we don't need design upgrade. We just said that we don't need design in detail upgrade. It's very good idea to get the high level design with the Y4 solids. See if we can come up with the high level design for story. So this would be the very simple architecture for my first story one. So we've got the application here, which will be talking to the streamer engine, which is already exist. We know the contracts, which will supply some data. We need to populate models somewhere in the application. So that whenever I do an awkward binding with that model, my newer would be reflected accordingly. So that's setting fair enough. That's the good starting point. So from this description, I know the when, right? So when application loads, we want to do something. So we got the trigger part. So I said when application loads, do something. For simplicity, I'm just making these sections. Now, I'm getting any hint apart from this. Any ideas? So we got one given, which is we need to construct the application. So, okay, I have created the, that's fair enough. Now, here are response from server, right? So that would be my verification. Now with whenever you do a unit testing or behavior testing, it's very important to control the output, to get to control the response. Now it's very tricky to get your all the test running when the application or the backend is not returning the concrete or the predefined response. If it's changing continuously, it's very tough to pass the test. So what I need is, I need some response that in real-time streamer engine or the backend would be returning. So I got some of the cheat codes with me that has the message already defined. Maybe at this stage, we can say, okay, it's not here with the first architecture. It's just the application, I don't know how the stuff will work. Okay, it's nice idea to hit the whiteboard again and do a bit more detailed discussion there. So let's go into the more detail. This is how there would be some evolution to the earlier design. So we know the contacts with the streamer engine will be sending slash instrument request to the streamer engine and that would be returning as a snapshot message. So when I say snapshot, it's the static data at that point. So whatever change at that point, and then there will be update message, that's the update, change data. Okay, so it's like an immediate snapshot message. So why do I need a channel? We need a way where we can short-circuit the integration layer. So then whatever this response we want, we have more control over that. So that's why channel is a very nice idea because that's give you flexibility to connect to the multiple packets based on the new. Okay, then we already got the application. Now we want to populate some model. So it's written in all the instruments. So it's kind of collections. So I need some container and that's where we got the instrument container. So the instrument, so we'll populate the instrument container and there will be some binding and that will take care of the UI. Okay, so this is giving much better clarity now. If we need a message, okay, we need that application. I need, I also need some instrument container model. Okay, so I create those variables with click. If you have any question at any time, please shout. We might use some of the time from the question and suggestion. It's very tough for in 30 minutes to cover such type of demonstration, but let's try. Because here we might not be using real because we want the stuff work. Okay, now I think we got the given part verification. Generally, we do a verification first. So what I'm expecting here is, I'm expecting my instrument container which is holding collection of instruments should populate equal to the snapshot message I got. So I'll say, I just traverse down this object. I'll get the, so this message is written in array and I'll say 0th element. So whatever coming from the packet, my model should be equal to that particular object. And similarly for second instrument as well. This is how my first acceptance looks like. So once, when application is loaded, you have the instrument container and the channel defined. Then I want my model to be populated with the business, with the instruments that's coming from the server. Okay, if I run this test, I'm going to complain about the, okay, we need to create those classes. Now I'll quickly switch over to another workspace where I'll show how this will trigger or how this will focus to, or how this could be a starting point to write the unit test. Now this will, this will ask us to, okay, define the application function class. Then write the load function. Now we will not be writing anything in load unless we write the test first. Okay, now I may not be able to code everything. Let me quickly switch back to the workspace where I have this domain is solved in story-wide and we quickly go over how it would have been evolved. Maybe I can switch the workspace. Okay, so go through the story one. So let's say if we have this similar acceptance test which we just got here, we increase the font size to larger. Yeah, so display all the instruments on application load. Okay, we got that. Then when application loads, then we created the application which containing instrument container and WebSocket channel. So here we are using WebSocket channel for test and these are the my associated. Now I should be seeing this test failing in the other workspace. Now this will evolve me to write the application class. So before writing load, I would have written the unit test. So the first unit of the particular load is request instrument snapshot on load. So whenever there is a load, then I'm expecting a same request over the WebSocket channel. And how do you mock in Jasmine? This is how you mock. So there are two ways. One is you create your object. The class is already defined, function is already defined. Then spy on any method, any function that you are interested within that object. And then you can verify assert in the verification section where particular interaction has been made or not. The other way is you can say Jasmine not create spy. And you can, this is just the name to refer inside the failure statements. So this is how on the fly you can create a spy object. And you can say, okay, then you can create a function and you can spy that particular function as well. So I would have done load. Then once the application is loaded, then we want, now it's a asking. So one thing, so the application loads job is just to make a request, snapshot request. It would be asking, so we need some listener there. So it says, it registers listener on the channel as well. So whenever there is a response, it will give the callback to the listener. And then another responsibility of this application would be whenever there is an on snapshot callback, whenever message comes from the packet, then add each invoke this interaction. So ask instrument container to add those instruments. Anil, we have to do a Qo session right now. Yes, two minutes. Okay, so this is how the test looks like for the application and then the my code evolves. So the idea is not to jump to the production code immediately. Whatever you requirement is from the technical perspective or the business perspective put that into the code first and then add production code. The benefit is you will find very clean code maintainable and if you say, I'll write production code, I'll write unit test later on. But believe me, it's very tough to write unit test after that because then no collaboration objects are separated properly. Doing the state-based testing is painful because your test grows lots of lines. And by doing this once it gives you, it's involved in design. So it's very flexible based on the requirement we can in the design. So let's see running the test. Now you can run all the test for this particular story. And Jasmine got all the support so you can easily integrate in Eclipse. You don't need to switch between two windows. It's one ID. And also it calls the Maven plugin so that you can put into the your build as well. I'm sorry, we can't see the application running on the browser. It was optimistic to cover all the stories because it takes quite a long time. I generally prefer this kind of in the workshop. So let's quickly go over the remaining PPDs if those make any sense. So story two would have evolved further design. Then story three would be another entity's collaboration. And this would have been driven all by test, unit test. So questions I need to wrap up, sorry. So when you spy on it just intercepts those methods also, right? Yeah, only those functions. So it's not a mocking library. It actually intercepts run-type messages. Yeah. And there are quite more metro in that sense because we suppose we want to spy on particular function but we also want actual execution. So you can spy on say, okay, spy on particular method and follow through. So it will execute the actual code as well where in the below we can verify whether the particular interaction has been made and if there is something test requires to be apart from the actual execution, we can achieve that as well. It's very unlikely but it has that support. What do you mean by that? What is the clean way to tear down? It has a before each and after each method. Jasmine got the support like set up and tear down. So we can see the before each here. Similarly there is a tear down after each block which is executed after each test. Jasmine got some function as well to clear any spy on objects. So that it clears everything for the next test. Here your server side application is what, Java or how the server side written it? It's a Java where it is embedded. So here Jasmine will be able to help you test most of your client side JavaScript except for the last leg of your JavaScript which actually makes the communication calls it would be hard to test that. Is that correct? Or will it be able to test against the actual HTTP request that go over the wire? So we can do the actual testing. So we can actually put the real channel. So if we go back through the this slide so this could be an actual channel and Jasmine is actually injecting the actual channel. That's very well possible in scenario where we know what that engine is written in. If that is written in finite set of instruments really fine. That's fine, we can adopt that output. But if it's a real engine and we don't know which instruments it will return those might be a flexibility in the sense like change or some of the data may not be same, which each time then I prefer it's a good idea client side because it's more faster to run and easy to maintain than they are looking at the package side. But yeah both are available. Any more questions? How to write that S? S is for asynchronous request. I mean what I'm placing most of the time because I use the Jasmine or Q unit. The second block as you could before false. In that case, how can we halt? But yeah in whatever applications I have worked whenever there is a sync we separate out into the two things two blocks. And we it was the unit test which was the doing the first part. So when you make a request though it's a we have to use the callback. Yeah, so callback. So you test the callback separate out and then you just test the mechanism of whether you are properly wiring your callback or not. So that's the one way which we have used. And apart from web sockets which other protocols you can spy on? We can spy on any function. There is no I mean if I want to create a channel to simulate a REST API behavior. Okay. And now I want to use that channel. Jasmine will be able to support. Yeah, I mean independent of any technology so this is just a channel to see the actual application running that's for the reason using the web sockets. But you can use any technology so you can use node.js whatever it doesn't matter for Jasmine. It's just the one integration there. Okay. Thank you guys.