Sprint 3 Retrospective

At the beginning of the third sprint we had some direction on what we were going to do finally. Of all the components we looked at we began to find the most interest in the bottom navigation bar. Our plan was to look at what might be needed to accomplish this component, and what direction we wanted to go with the development. However, that all changed when we decided to work on the server. We knew that the server was a vital piece of this app as every team would need that to continue. We wanted to make sure that everyone would be able to do their work, and were up to the task so we switched focus to this.

A majority of the time we were looking into the server we spent tracing the requests of the ampath project. We pinned down the location of the services to the src>app>openmrs-api folder. We noticed that the calls to the server were URL’s and that the links to the server were being called to connect. We needed to find a way to successfully mock this server call in order to pass tests that we might use. With a little research I came across NOCK. NOCK defines its process as “Nock works by overriding Node’s http.request function. Also, it overides http.ClientRequest too to cover for modules that use it directly.”[1] What in my basic understanding of NOCK believes this means is that it creates fake stubs that return preset data instead of connecting to the web and pulling from the server. This looks like the successful route to take if we wanted to continue with the project as these mocks could easily be switched out for the real URLs and work with minimal code change.

Now came the tedious part of tracking down each and every service that we needed to mock and creating a backlog to work on. Once the service was identified we would go and mock the service and push it for use. This is when another discovery occurred as I was tracking down the paths and finding the important services I discovered what appears to already be a mocking tool built in. At this time I am not certain on how it works and if this is true, but it appears that the files that end with “.spec” have built in testing equipment as it stands. Which can be seen in the example below, but what we need to figure out now is if this is viable to be used by us or if we are still going to need to mock the information. Although we haven’t produced anything as of yet I have learned some information about mocking servers, and reading through other peoples code and I believe that to be valuable. On the other hand I am excited to start producing and I think that will be a large part of the next sprint as we have started to iron out the finer details at this point.

-Coding Finn

[1] https://github.com/nock/nock

beforeEach(()
=> {
TestBed.configureTestingModule({
providers: [
PatientRelationshipResourceService,
AppSettingsService,
LocalStorageService
],
imports: [
HttpClientTestingModule]
});
service = TestBed.get(PatientRelationshipResourceService);
httpMock = TestBed.get(HttpTestingController);
});

afterEach(() => {
httpMock.verify();
TestBed.resetTestingModule();
});

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at WordPress.com.

Up ↑

Create your website at WordPress.com
Get started
%d bloggers like this: