Unit Test case for services method in angular
Personally i would create an interface for the expected data from the backend. any is something i try to avoid, because then my IDE can´t help me finding my stupid mistakes.
For example
interface DynamicFormData {
   aValue: string,
   anotherValue: number,
}

async getDynamicFormData(paramName: string, data?: SomeDataType): Promise&lt;DynamicFormData &gt; {
  return await this.http.get(this.HostUrl + paramName).toPromise();
}

It gives you the benefit, that whereever you call that method, the IDE will know how the data will look like and what methods could be performed on it.
Also personally i like working with RxJS more than Promises, but thats a personal habit. But it allows to filter, modify, do stuff on the response. And i stay away from &quot;async/await&quot;, because i do not like blocking tasks in my frontend if i can avoid them. But as i said, personal style.
About the init of the testcases, why do you need to import the RouterTestingModule? Its not used in the service at all.
About the test coverage:
When i see a method interface like getDynamicFormData(paramName: any, data?: any) then i would ask myself if &quot;paramName&quot; is mandatory or not. Also test cases are a kind of documentation, therefore i would add a testcase with an empty paramName (for example null).
From a Unit-testing perspective i would avoid hard coded strings like &quot;account-type&quot;. You will surely use this strings also at other places in the regular code when you want to call the service. If those strings change, you have to find all places where they are used and replace them. Therefore i would create constants for those and us those constants. Then if the API changes ( e.g. &quot;account-type&quot; changes to &quot;type-of-account&quot;) you just have to change it at one place and all (code and unit test) will adept automaticly.
You specificly asked in the comment for &quot;code-coverage&quot;.
For that we have to think about what could be the possible results of each method. The Promise could be resolved or fail. Quite easy.
BUT your service is instantiated with a parameter
constructor(private handler: HttpBackend) {
    this.http = new HttpClient(handler);
 }

If you do not provide any input (as you do in your unit test), then its instantiated with this.http = new HttpClient();. I always use the HTTPClient provided directly by Angular, therefor i do not really know the effect of this. From the documentation it seems that this would circumvent the interceptors. But be it as it be, as its an input that may alter the behavior of your service, its something that should be covered by your testcases.
Hope you could use some of the mentioned things. :-)
warm regards
Jan