Jaichand Khatik

Hi, I'm Jason. I have around 8.8 years of experience. I'm mainly working on the 8.8 percent of my experience working on web development. And my core contributions to the organizations are, like, writing the component library and, also, writing the component library and making the micro frontend area for the React Native mobile applications.

When it comes to the Jenkins applications, we have to check. When it comes to the Jenkins pipeline, which is breaking, there will be some error specifically. Go to the Jenkins pipeline. Click on that. It will give you a specific reason where it is failing and the reason for failing. So, mostly, if there are no changes in recent work, then there is a problem somewhere, like, on the change itself. There might be some environment issue or a problem related to the plug-in.

Yes, test cases are very first important. So whenever the direct line is not, let's say if it's tight deadlines are there. So very first, you will be writing the test cases in this starting. Like, whenever you're taking the requirement gathering, that time you will be firstly writing the test cases and then you will be writing your code. So in that case, your testing will be more easier. Like, you need not to do this specific unit test. So your test cases will be giving you the help that could be there. The test cases are working fine or not. So if I have to specifically plan for it, how can we do it? So there is a very first step, whenever the application is getting started, the requirement gathering is happening, and you understand that these are the things which have to be built. Write your test cases in the starting. Once that is there, then start building the application tools.

Yeah. So, whenever you're introducing a library, you assume that all the research has already been done. And then, the decision has been made that we have to introduce that library. So, in that case, whenever the library is getting introduced, you have to check where you're starting, like, once that application is built, the library is introduced. There's no legacy break. In case the legacy exists, you have to provide specific things for the legacy first, and then choose the specific parts. These are the parts I'll be touching at the start. I'll be testing with them. And, let's say instead of working on the whole application, you can choose small chunks, and I'll finish one x project. Yeah. One x piece with this library, and then object to how things are going. In case everything is fine and it's working correctly, the library is already working fine, you'll observe for some time, and then start with the rest of the applications. Instead of adding these changes to the whole application, it'll be great to implement one piece of the application at a time, and then move on to the next things.

The approach for test-driven development is, like, whenever you're done with starting your application, the very first thing you do is write all your test cases, the failure test cases, the success test cases, and all the scenarios. Let's say you should be covering your test cases whenever you're writing around 80%. And once your test cases are done, then you start writing the code. So, whenever you're writing a functionality, you cross-check with your test case. So, you run your test case, and you check what things are getting success. So, whenever you're pushing your code, you make sure you have 100% test coverage out there. Whatever test cases you have written, which cover 80% of your code, you push your code after that.

So here, users ID. Okay. So whenever the user ID is there, await user dot find. Okay. It will give you the user, and then it is doing this part. So okay. So there is a, here, the one thing is that we are doing a whole users fetch. We are fetching first. And after that, we are filtering and we are sending it back to the front end. So it will be great, like, you do the query with the specific ID instead of finding the whole users table. So let's say, like, you just don't find the user by ID equal to something or find the one. There are some more queries which we can use. And if we have to use it, something like this only, then it is going to be time-consuming in that case.

Try, catch, let, s. Okay. That's data. Alright. So whenever it's written, right, that response of the first whenever you're using a fetch, then it will return you a REST promise. And, whenever, like, a response.json is also returning your promise. So they should await whenever you are sending the data back. Otherwise, that response.json won't be resolved before you're pushing the datasets. Better you add an await on the response.json before response.json. Yeah. We'll use the async of it only, but I will add two awaits. Like, the first is for the response and then the response.json is also a promise.

So whenever it comes to the data's database schema migration, there are a lot of possibilities which we have to keep in mind. So, very first, the production will not be touched before it is getting tested. So, very first, it will be tested on the dev environment, then it will be on the stage environment. And, if we have something in between, let's say QA environment or something, we'll be testing it there. And to make it better, like, the very first order of the schema, it could change and whatever things are already added. So, very first, what we will be doing is, we will be running our migrations. On those migrations, we will be updating our database first. And then we will be updating the keys which are newly added first. Let's see if we have to use the same database schema, which has got modified instead of just changing gin. So in that case, we will be creating a new database schema and running our scripts like a migration script we have to write. In those migration scripts, we will be running all the data things and getting it. This is an efficient way of handling database. In these migrations, we will also be adding all of our failure things as well. Like, let's say, failure cases in case if they could fail at any place. So we will be capturing those things as well. And should we cascade? We have to use cascading. Yes. Like, in case if it is failing at any point, we will roll back and then start doing from the scratch or whatever the place it could fail. We'll be adding that.