Libetia A

Libetia A

1565835932

An Introduction to Unit Testing in Angular

JavaScript is a dynamically typed language which comes with great power of expression, but it also comes with almost no help from the compiler. For this reason we feel very strongly that any code written in JavaScript needs to come with a strong set of tests. We have built many features into AngularJS which make testing your AngularJS applications easy. With AngularJS, there is no excuse for not testing.

Separation of Concerns

Unit testing, as the name implies, is about testing individual units of code. Unit tests try to answer questions such as “Did I think about the logic correctly?” or “Does the sort function order the list in the right order?”

In order to answer such a question it is very important that we can isolate the unit of code under test. That is because when we are testing the sort function we don’t want to be forced into creating related pieces such as the DOM elements, or making any XHR calls to fetch the data to sort.

While this may seem obvious it can be very difficult to call an individual function on a typical project. The reason is that the developers often mix concerns resulting in a piece of code which does everything. It makes an XHR request, it sorts the response data, and then it manipulates the DOM.

With AngularJS, we try to make it easy for you to do the right thing. For your XHR requests, we provide dependency injection, so your requests can be simulated. For the DOM, we abstract it, so you can test your model without having to manipulate the DOM directly. Your tests can then assert that the data has been sorted without having to create or look at the state of the DOM or to wait for any XHR requests to return data. The individual sort function can be tested in isolation.

With great power comes great responsibility

AngularJS is written with testability in mind, but it still requires that you do the right thing. We tried to make the right thing easy, but if you ignore these guidelines you may end up with an untestable application.

Dependency Injection

AngularJS comes with dependency injection built-in, which makes testing components much easier, because you can pass in a component’s dependencies and stub or mock them as you wish.

Components that have their dependencies injected allow them to be easily mocked on a test by test basis, without having to mess with any global variables that could inadvertently affect another test.

Additional tools for testing AngularJS applications

For testing AngularJS applications there are certain tools that you should use that will make testing much easier to set up and run.

Karma

Karma is a JavaScript command line tool that can be used to spawn a web server which loads your application’s source code and executes your tests. You can configure Karma to run against a number of browsers, which is useful for being confident that your application works on all browsers you need to support. Karma is executed on the command line and will display the results of your tests on the command line once they have run in the browser.

Karma is a NodeJS application, and should be installed through npm/yarn. Full installation instructions are available on the Karma website.

Jasmine

Jasmine is a behavior driven development framework for JavaScript that has become the most popular choice for testing AngularJS applications. Jasmine provides functions to help with structuring your tests and also making assertions. As your tests grow, keeping them well structured and documented is vital, and Jasmine helps achieve this.

In Jasmine we use the describe function to group our tests together:

describe("sorting the list of users", function() {
  // individual tests go here
});

And then each individual test is defined within a call to the it function:

describe('sorting the list of users', function() {
  it('sorts in descending order by default', function() {
    // your test assertion goes here
  });
});

Grouping related tests within describe blocks and describing each individual test within an it call keeps your tests self documenting.

Finally, Jasmine provides matchers which let you make assertions:

describe('sorting the list of users', function() {
  it('sorts in descending order by default', function() {
    var users = ['jack', 'igor', 'jeff'];
    var sorted = sortUsers(users);
    expect(sorted).toEqual(['jeff', 'jack', 'igor']);
  });
});

Jasmine comes with a number of matchers that help you make a variety of assertions. You should read the Jasmine documentation to see what they are. To use Jasmine with Karma, we use the karma-jasmine test runner.

angular-mocks

AngularJS also provides the ngMock module, which provides mocking for your tests. This is used to inject and mock AngularJS services within unit tests. In addition, it is able to extend other modules so they are synchronous. Having tests synchronous keeps them much cleaner and easier to work with. One of the most useful parts of ngMock is $httpBackend, which lets us mock XHR requests in tests, and return sample data instead.

Testing a Controller

Because AngularJS separates logic from the view layer, it keeps controllers easy to test. Let’s take a look at how we might test the controller below, which provides $scope.grade, which sets a property on the scope based on the length of the password.

angular.module('app', [])
.controller('PasswordController', function PasswordController($scope) {
  $scope.password = '';
  $scope.grade = function() {
    var size = $scope.password.length;
    if (size > 8) {
      $scope.strength = 'strong';
    } else if (size > 3) {
      $scope.strength = 'medium';
    } else {
      $scope.strength = 'weak';
    }
  };
});

Because controllers are not available on the global scope, we need to use angular.mock.inject to inject our controller first. The first step is to use the module function, which is provided by angular-mocks. This loads in the module it’s given, so it is available in your tests. We pass this into beforeEach, which is a function Jasmine provides that lets us run code before each test. Then we can use inject to access $controller, the service that is responsible for instantiating controllers.

describe('PasswordController', function() {
  beforeEach(module('app'));

  var $controller, $rootScope;

  beforeEach(inject(function(_$controller_, _$rootScope_){
    // The injector unwraps the underscores (_) from around the parameter names when matching
    $controller = _$controller_;
    $rootScope = _$rootScope_;
  }));

  describe('$scope.grade', function() {
    it('sets the strength to "strong" if the password length is >8 chars', function() {
      var $scope = $rootScope.$new();
      var controller = $controller('PasswordController', { $scope: $scope });
      $scope.password = 'longerthaneightchars';
      $scope.grade();
      expect($scope.strength).toEqual('strong');
    });
  });
});

Notice how by nesting the describe calls and being descriptive when calling them with strings, the test is very clear. It documents exactly what it is testing, and at a glance you can quickly see what is happening. Now let’s add the test for when the password is less than three characters, which should see $scope.strength set to “weak”:

describe('PasswordController', function() {
  beforeEach(module('app'));

  var $controller;

  beforeEach(inject(function(_$controller_){
    // The injector unwraps the underscores (_) from around the parameter names when matching
    $controller = _$controller_;
  }));

  describe('$scope.grade', function() {
    it('sets the strength to "strong" if the password length is >8 chars', function() {
      var $scope = {};
      var controller = $controller('PasswordController', { $scope: $scope });
      $scope.password = 'longerthaneightchars';
      $scope.grade();
      expect($scope.strength).toEqual('strong');
    });

    it('sets the strength to "weak" if the password length <3 chars', function() {
      var $scope = {};
      var controller = $controller('PasswordController', { $scope: $scope });
      $scope.password = 'a';
      $scope.grade();
      expect($scope.strength).toEqual('weak');
    });
  });
});

Now we have two tests, but notice the duplication between the tests. Both have to create the $scope variable and create the controller. As we add new tests, this duplication is only going to get worse. Thankfully, Jasmine provides beforeEach, which lets us run a function before each individual test. Let’s see how that would tidy up our tests:

describe('PasswordController', function() {
  beforeEach(module('app'));

  var $controller;

  beforeEach(inject(function(_$controller_){
    // The injector unwraps the underscores (_) from around the parameter names when matching
    $controller = _$controller_;
  }));

  describe('$scope.grade', function() {
    var $scope, controller;

    beforeEach(function() {
      $scope = {};
      controller = $controller('PasswordController', { $scope: $scope });
    });

    it('sets the strength to "strong" if the password length is >8 chars', function() {
      $scope.password = 'longerthaneightchars';
      $scope.grade();
      expect($scope.strength).toEqual('strong');
    });

    it('sets the strength to "weak" if the password length <3 chars', function() {
      $scope.password = 'a';
      $scope.grade();
      expect($scope.strength).toEqual('weak');
    });
  });
});

We’ve moved the duplication out and into the beforeEach block. Each individual test now only contains the code specific to that test, and not code that is general across all tests. As you expand your tests, keep an eye out for locations where you can use beforeEach to tidy up tests. beforeEach isn’t the only function of this sort that Jasmine provides, and the documentation lists the others.

Testing Filters

Filters are functions which transform the data into a user readable format. They are important because they remove the formatting responsibility from the application logic, further simplifying the application logic.

myModule.filter('length', function() {
  return function(text) {
    return ('' + (text || '')).length;
  }
});

describe('length filter', function() {

  var $filter;

  beforeEach(inject(function(_$filter_){
    $filter = _$filter_;
  }));

  it('returns 0 when given null', function() {
    var length = $filter('length');
    expect(length(null)).toEqual(0);
  });

  it('returns the correct value when given a string of chars', function() {
    var length = $filter('length');
    expect(length('abc')).toEqual(3);
  });
});

Testing Directives

Directives in AngularJS are responsible for encapsulating complex functionality within custom HTML tags, attributes, classes or comments. Unit tests are very important for directives because the components you create with directives may be used throughout your application and in many different contexts.

Simple HTML Element Directive

Let’s start with an AngularJS app with no dependencies.

var app = angular.module('myApp', []);

Now we can add a directive to our app.

app.directive('aGreatEye', function () {
    return {
        restrict: 'E',
        replace: true,
        template: '<h1>lidless, wreathed in flame, {{1 + 1}} times</h1>'
    };
});

This directive is used as a tag <a-great-eye></a-great-eye>. It replaces the entire tag with the template <h1>lidless, wreathed in flame, {{1 + 1}} times</h1>. Now we are going to write a jasmine unit test to verify this functionality. Note that the expression {{1 + 1}} times will also be evaluated in the rendered content.

describe('Unit testing great quotes', function() {
  var $compile,
      $rootScope;

  // Load the myApp module, which contains the directive
  beforeEach(module('myApp'));

  // Store references to $rootScope and $compile
  // so they are available to all tests in this describe block
  beforeEach(inject(function(_$compile_, _$rootScope_){
    // The injector unwraps the underscores (_) from around the parameter names when matching
    $compile = _$compile_;
    $rootScope = _$rootScope_;
  }));

  it('Replaces the element with the appropriate content', function() {
    // Compile a piece of HTML containing the directive
    var element = $compile("<a-great-eye></a-great-eye>")($rootScope);
    // fire all the watches, so the scope expression {{1 + 1}} will be evaluated
    $rootScope.$digest();
    // Check that the compiled element contains the templated content
    expect(element.html()).toContain("lidless, wreathed in flame, 2 times");
  });
});

We inject the $compile service and $rootScope before each jasmine test. The $compile service is used to render the aGreatEye directive. After rendering the directive we ensure that the directive has replaced the content and “lidless, wreathed in flame, 2 times” is present.

Underscore notation: The use of the underscore notation (e.g.: _$rootScope_) is a convention wide spread in AngularJS community to keep the variable names clean in your tests. That’s why the $injector strips out the leading and the trailing underscores when matching the parameters. The underscore rule applies only if the name starts and ends with exactly one underscore, otherwise no replacing happens.

Testing Transclusion Directives

Directives that use transclusion are treated specially by the compiler. Before their compile function is called, the contents of the directive’s element are removed from the element and provided via a transclusion function. The directive’s template is then appended to the directive’s element, to which it can then insert the transcluded content into its template.

Before compilation:

<div transclude-directive>
  Some transcluded content
</div>

After transclusion extraction:

<div transclude-directive></div>

After compilation:

<div transclude-directive>
  Some Template
  <span ng-transclude>Some transcluded content</span>
</div>

If the directive is using ‘element’ transclusion, the compiler will actually remove the directive’s entire element from the DOM and replace it with a comment node. The compiler then inserts the directive’s template “after” this comment node, as a sibling.

Before compilation

<div element-transclude>
  Some Content
</div>

After transclusion extraction

<!-- elementTransclude -->

After compilation:

<!-- elementTransclude -->
<div element-transclude>
  Some Template
  <span ng-transclude>Some transcluded content</span>
</div>

It is important to be aware of this when writing tests for directives that use ‘element’ transclusion. If you place the directive on the root element of the DOM fragment that you pass to $compile, then the DOM node returned from the linking function will be the comment node and you will lose the ability to access the template and transcluded content.

var node = $compile('<div element-transclude></div>')($rootScope);
expect(node[0].nodeType).toEqual(node.COMMENT_NODE);
expect(node[1]).toBeUndefined();

To cope with this you simply ensure that your ‘element’ transclude directive is wrapped in an element, such as a <div>.

var node = $compile('<div><div element-transclude></div></div>')($rootScope);
var contents = node.contents();
expect(contents[0].nodeType).toEqual(node.COMMENT_NODE);
expect(contents[1].nodeType).toEqual(node.ELEMENT_NODE);

Testing Directives With External Templates

If your directive uses templateUrl, consider using karma-ng-html2js-preprocessor to pre-compile HTML templates and thus avoid having to load them over HTTP during test execution. Otherwise you may run into issues if the test directory hierarchy differs from the application’s.

Testing Promises

When testing promises, it’s important to know that the resolution of promises is tied to the digest cycle. That means a promise’s then, catch and finally callback functions are only called after a digest has run. In tests, you can trigger a digest by calling a scope’s $applyfunction. If you don’t have a scope in your test, you can inject the $rootScope and call $apply on it. There is also an example of testing promises in the $q service documentation.

**Using **<strong>beforeAll()</strong>

Jasmine’s beforeAll() and mocha’s before() hooks are often useful for sharing test setup - either to reduce test run-time or simply to make for more focused test cases.

By default, ngMock will create an injector per test case to ensure your tests do not affect each other. However, if we want to use beforeAll(), ngMock will have to create the injector before any test cases are run, and share that injector through all the cases for that describe. That is where module.sharedInjector() comes in. When it’s called within a describe block, a single injector is shared between all hooks and test cases run in that block.

In the example below we are testing a service that takes a long time to generate its answer. To avoid having all of the assertions we want to write in a single test case, module.sharedInjector() and Jasmine’s beforeAll() are used to run the service only once. The test cases then all make assertions about the properties added to the service instance.

describe("Deep Thought", function() {

  module.sharedInjector();

  beforeAll(module("UltimateQuestion"));

  beforeAll(inject(function(DeepThought) {
    expect(DeepThought.answer).toBeUndefined();
    DeepThought.generateAnswer();
  }));

  it("has calculated the answer correctly", inject(function(DeepThought) {
    // Because of sharedInjector, we have access to the instance of the DeepThought service
    // that was provided to the beforeAll() hook. Therefore we can test the generated answer
    expect(DeepThought.answer).toBe(42);
  }));

  it("has calculated the answer within the expected time", inject(function(DeepThought) {
    expect(DeepThought.runTimeMillennia).toBeLessThan(8000);
  }));

  it("has double checked the answer", inject(function(DeepThought) {
    expect(DeepThought.absolutelySureItIsTheRightAnswer).toBe(true);
  }));

});

Sample project

See the angular-seed project for an example.

Thanks For Visiting, Keep Visiting.

#angular #angular-js #typescript #testing #web-development

What is GEEK

Buddha Community

An Introduction to Unit Testing in Angular
Roberta  Ward

Roberta Ward

1593144120

Basic Introduction to Unit Testing in Angular

What is Unit Testing?

Unit testing is testing a unit in an isolated environment. A unit can be a class, component, service, directive module, etc. which can be logically separated from the software. Any unit in an app is not isolated, it’s quite normal that it will be depending on the other units in an application for resources like data or methods.

So if we do an integrated test of the application and it fails then it’s hard to identify where exactly the code is breaking. So the purpose of unit testing is to test each unit individually and see if it’s working fine.

Benefits of Unit Testing

Reveal design mistakes

You may encounter difficulty while writing tests which might reveal that the design is not correct and you may be violating some important coding principles. Or after running the test it shows unexpected behavior.

Add new features without breaking anything

If you add any new feature into existing code and after running test passes then you can be confident it won’t break the application.

Simplifies debugging process

As discussed earlier it makes it easy to exactly identify where the code is breaking.

Tests make developers more confident about their work

So, we will understand unit testing in angular by looking at some basic simple examples and then getting to know why and how we have done.

#angular #angular #angular9 #jasmine #karma #testing #unit tesing in angular #unit testing

Software Testing 101: Regression Tests, Unit Tests, Integration Tests

Automation and segregation can help you build better software
If you write automated tests and deliver them to the customer, he can make sure the software is working properly. And, at the end of the day, he paid for it.

Ok. We can segregate or separate the tests according to some criteria. For example, “white box” tests are used to measure the internal quality of the software, in addition to the expected results. They are very useful to know the percentage of lines of code executed, the cyclomatic complexity and several other software metrics. Unit tests are white box tests.

#testing #software testing #regression tests #unit tests #integration tests

Tamia  Walter

Tamia Walter

1596754901

Testing Microservices Applications

The shift towards microservices and modular applications makes testing more important and more challenging at the same time. You have to make sure that the microservices running in containers perform well and as intended, but you can no longer rely on conventional testing strategies to get the job done.

This is where new testing approaches are needed. Testing your microservices applications require the right approach, a suitable set of tools, and immense attention to details. This article will guide you through the process of testing your microservices and talk about the challenges you will have to overcome along the way. Let’s get started, shall we?

A Brave New World

Traditionally, testing a monolith application meant configuring a test environment and setting up all of the application components in a way that matched the production environment. It took time to set up the testing environment, and there were a lot of complexities around the process.

Testing also requires the application to run in full. It is not possible to test monolith apps on a per-component basis, mainly because there is usually a base code that ties everything together, and the app is designed to run as a complete app to work properly.

Microservices running in containers offer one particular advantage: universal compatibility. You don’t have to match the testing environment with the deployment architecture exactly, and you can get away with testing individual components rather than the full app in some situations.

Of course, you will have to embrace the new cloud-native approach across the pipeline. Rather than creating critical dependencies between microservices, you need to treat each one as a semi-independent module.

The only monolith or centralized portion of the application is the database, but this too is an easy challenge to overcome. As long as you have a persistent database running on your test environment, you can perform tests at any time.

Keep in mind that there are additional things to focus on when testing microservices.

  • Microservices rely on network communications to talk to each other, so network reliability and requirements must be part of the testing.
  • Automation and infrastructure elements are now added as codes, and you have to make sure that they also run properly when microservices are pushed through the pipeline
  • While containerization is universal, you still have to pay attention to specific dependencies and create a testing strategy that allows for those dependencies to be included

Test containers are the method of choice for many developers. Unlike monolith apps, which lets you use stubs and mocks for testing, microservices need to be tested in test containers. Many CI/CD pipelines actually integrate production microservices as part of the testing process.

Contract Testing as an Approach

As mentioned before, there are many ways to test microservices effectively, but the one approach that developers now use reliably is contract testing. Loosely coupled microservices can be tested in an effective and efficient way using contract testing, mainly because this testing approach focuses on contracts; in other words, it focuses on how components or microservices communicate with each other.

Syntax and semantics construct how components communicate with each other. By defining syntax and semantics in a standardized way and testing microservices based on their ability to generate the right message formats and meet behavioral expectations, you can rest assured knowing that the microservices will behave as intended when deployed.

Ways to Test Microservices

It is easy to fall into the trap of making testing microservices complicated, but there are ways to avoid this problem. Testing microservices doesn’t have to be complicated at all when you have the right strategy in place.

There are several ways to test microservices too, including:

  • Unit testing: Which allows developers to test microservices in a granular way. It doesn’t limit testing to individual microservices, but rather allows developers to take a more granular approach such as testing individual features or runtimes.
  • Integration testing: Which handles the testing of microservices in an interactive way. Microservices still need to work with each other when they are deployed, and integration testing is a key process in making sure that they do.
  • End-to-end testing: Which⁠—as the name suggests⁠—tests microservices as a complete app. This type of testing enables the testing of features, UI, communications, and other components that construct the app.

What’s important to note is the fact that these testing approaches allow for asynchronous testing. After all, asynchronous development is what makes developing microservices very appealing in the first place. By allowing for asynchronous testing, you can also make sure that components or microservices can be updated independently to one another.

#blog #microservices #testing #caylent #contract testing #end-to-end testing #hoverfly #integration testing #microservices #microservices architecture #pact #testing #unit testing #vagrant #vcr

Jamal  Lemke

Jamal Lemke

1603587600

Agile Testing: An introduction

When we talk about Agile the first thing that pops into our mind is Agile development. But here we are going to see and learn about an introduction to Agile Testing that how testers work in Agile, the contrast between Agile Testing and development, and traditional vs. Agile approach.

What is Agile Testing?

  • In the world of software development, there are two very common terminologies, Developers (programmers) and testers. When we hear programmer we think of a person whose main task is to write production code. And when you hear tester you think of a person whose main task in testing and quality assurance.
  • In Agile no one has only one task to perform, here everyone works on it with one aim in the mind that is to deliver the quality their customers need. In a traditional approach, this would have been the primary concern of the tester or the QA of the team. But in Agile even the development team tries to deliver quality end product to the customer.
  • Agile is an iterative development methodology, where requirements evolve through collaboration between the customer and self-organizing teams. Agile aligns development with customer needs. Several core practices used by agile teams relate to testing.
  • Test-driven development (TDD) is used for the development of the services. Where the programmer writes the tiny piece of test which fails. Then tries to write the code around it to make the test pass. It is an approach that many teams follows as it is a smart technique to avoid any bugs.

ROLES AND ACTIVITIES ON AN AGILE TEAM

The roles are divided into mainly two teams:

  • Customer team
  • Developer team
Customer team
  • The customer team comprises business experts, product owners, domain experts, product managers, business analysts, etc. The customer team writes the stories for the development to work on. They provide examples and logic behind the requirements. Their main task is to clear any doubts and give clarification with real world use cases or examples. They are available in each iteration for guiding the Dev and QA teams as well.
  • In a customer team, the testers have a crucial role to play. They help the customers express their requirements as tests.
Developer team
  • The developer team comprises of Developer team includes programmers,system administrators, architects, database administrators, technical writers,security specialists. Each person in the team can be responsible for multiple roles. A developer can also be helping out in testing related activities and a tester could be helping the developers in debugging a issue.
  • Testers are in the developer team as well because testing is one of the core tasks in Agile. Both the testers and the developers help each other in achieving the best quality end product for the customer.

Interaction between Customer and Developer Teams

  • The customer and developer teams work closely together with a common goal to deliver value to the organisation. Testers does not have the sole responsibility for the quality of the product under development. The developer also helps them achieve this by trying to maintain the quality from the first phase of the development.
  • The customer team with developer team prioritise stories which are crucial and are to delivered in each sprint. It’s totally up to the customer that what they want the developer team to work on. They can even request changes in between the sprint and the developer can work on it. If it does not affect the current scope of the story too much. Even if it does they can pick it up in the next upcoming sprint.
  • It is not totally in the hands of the customer team to dictate how much work they want the development team to work on. The developer picks up work according to there bandwidth, estimates it and then starts working on it.
  • Testers have a foot in each world, understanding the customer viewpoint as well as the complexities of the technical implementation. The testers or the QA team acts as a bridge between the customer and the developers. They don’t just understands the customer requirements but also looks at it from a technical viewpoint. and tries to see if it is feasible or not from the developers point of view as well.

**HOW IS AGILE TESTING DIFFERENT? **

  • By now you must be wondering how is Agile testing different from the the other traditional approach? Let’s see how it is like to work on a traditional team vs. an Agile team.

Working on Traditional Teams

  • In traditional team or approach the testers are not involved with developers from the starting phases of the software. Testers are involved in the last phases of the development where they get very little time to test the services on which the developers works for months.
  • Each release cycle is for around 6 months where all the tasks are to be completed and released to the customer. Testers are involved in release planning and requirements definition.But after that they are involved in the end with rushed testing phase and sometimes a delayed release as well.
  • The quality is the sole responsibility of the QA team only. If any of the requirements were missing or any other issue was found the testers were responsible. They didn’t even have the control over if the developer has even tested there code or not.
  • The testers have the power to stop or postpone the release of they find any major issues in the release or if it is not according to the requirements.
  • 6 months seems like a very long time but is not as even after this time the end result is not according to the customers expectations. Things gets deviated from the path and the end result is not covering all the requirements.
  • The testers create there test plans according to the API specs but if the end product is not according to the defined requirements then the whole test plan simply fails.

#agile #api testing #integration testing #quality assurance (qa) #scaled agile #scrum #testing #unit testing #agile teams #agile transformation #test automation

Royce  Reinger

Royce Reinger

1625831220

Unit testing in Angular

Writing simple isolated unit test

Unit tests are a very important part of the programming process. Over the years it gains more and more traction. Going the path from exotics and, sometimes, weird implementation, extreme practices like TDD. From the geek’s toy to the mainstream. From the back-end to the front-end. Now unit tests are a “must-have” tool in the professional programmer’s toolset. This small article will tell about the front-end unit testing with Angular by using built-in test tools Karma and jasmine.

Types of automated tests.

There are 3 main types of automated tests. There are no strict borders between them and it can be arguably hard to decide which test falls in which category.

Unit testing — test of one “unit” of code. It can be a class, or method, with mocked dependencies. We will use this type of test here.

Integration testing — Few classes testing integrated. For example, for the back-end, it can be service and repository testing together, or service and component testing for the front-end.

End to end testing — full application testing, from front-end to back-end, that’s why it is called a (front) end to (back) end testing. In these tests usually live services using and nothing is mocked. it fully reproduces the real application work.

The task — unit test of the method.

Let’s imagine that we already have the simple Angular application — well known “Tour of heroes”. And we want to validate the name of the hero by its length. Let’s imagine that we don’t want the hero’s name less than 3 symbols.

#angular #unit-testing #unit-test-tools