Angular Testing
License and Copyright Notice
By submitting this issue or commenting on this issue, or contributing any content to this issue, you certify under the Developer Certificate of Origin that the content you post may be licensed under GPLv3 (for code) or CC-BY-SA 4.0 International (for non-code content).
What is the goal or the problem, and why is it important?
For the team to understand angular testing implementation.
How are you going to acheive the goal or solve the problem?
The team will research angular documentation.
What will be produced as a result of this effort and where will it live on GitLab?
This knowledge will be used for our front end code implementation.
Give a justification of weight or due date.
We gave this issue a weight of 2 becaus it will take time to research but actually implementing these tests is dependent on our code development.
Who will do it, and what will they do?
The whole team will research angular testing documentation.
What was the outcome?
The outcome will be a team wide understanding of angular testing for our front end code.
Template Version 1.0.0
Project Results Write-Up
For this spike project, I followed Angular’s testing documentation (https://angular.io/guide/testing). Additionally, I watched a video by Programming with Mosh about the topic, which also contains more general testing concepts as a review (https://www.youtube.com/watch?v=yG4FH60fhUE).
The project can be found here: https://gitlab.com/jyoung704/angular-testing-spike-project
Each commit describes what was added. Checking out commits individually and running the tests will allow you to see incremental changes.
Angular’s default testing suite is Jasmine, with Karma test runner. These make it very easy to begin testing with Angular, simply by running the “ng test” command. It will also listen for changes and re-run tests as you modify your code.
Because Angular CLI can generate components for you, the test file ending in “spec.ts” will already exist. This makes unit testing very simple.
There are notable features such as setting minimum code coverage or generating test reports. This may prove valuable as the project grows.
In Jasmine, it is important to understand that the describe() function is defining a test suite, which generally contains multiple it() functions that define a specific test. Each one of these takes two arguments: a name and a function. For more specifics and a description of other methods see here: https://jasmine.github.io/2.0/introduction.html
Failed tests can be viewed directly in the browser, but there is also a debug mode. Enter Debug mode by clicking the “debug” button. This mode will print the results of each test to the browser console. It will also show the traceback for failed tests, with links to the lines of code that failed to make it easy to debug.
Test naming is supposed describe what the test is doing, which is the reason the function containing the tests is called it(), and the reason they are contained in the describe() function. The expectation, which is the first argument to the function, is supposed to read as a sentence when combined with the it() function, answering “What should the object under test do?”
it(‘should say hello’, [function])Tests need not be created for components alone. Jasmine will look for any files ending in “.spec.ts”, which allows you to write a test for a standalone file which is used within a component. This is especially useful for testing any methods you may write within a class.
Once familiarized with the syntax, Angular testing is quite similar to any other testing suites. The links above should be more than sufficient to complete testing on our implementations.