Fixing and running tests

Before we dive into continuous integration tools, let's first make sure that our tests are working and still pass after the changes we made in the previous chapter. In an ideal world, where software development is done using practices such as TDD (Test-driven development), writing and fixing tests is done along with the development of the code, and specs are written before you develop the actual code. You should try to follow this practice so that you write failing tests first for an expected result, and then develop code that will make the tests pass. Since our tests were autogenerated by JHipster we can at least make sure that they are working when we make changes to the generated code.

JHipster can also generate performance tests using Gatling for the entities. It is very useful, and a must if you are developing a high-availability and high-volume website. This can be enabled when creating the application. See http://www.jhipster.tech/running-tests/ for more details. 

Let's run our unit and integration tests to see if any of them fail:

  1. Head over to your terminal and navigate to the online-store folder first.
  2. Let's first run the server-side tests using Gradle:
> ./gradlew test
Note that JHipster generates both unit tests and integration tests for the server side. The unit tests, files named *UnitTest.java, are simple JUnit tests intended for unit testing functions. The integration tests, files named *IntTest.java, are intended for testing a Spring component using the entire Spring environment. They are run with the SpringRunner class and normally start up the Spring environment, configure all the required beans, and run the test.

Some of our tests failed with the following error trace:

com.mycompany.store.web.rest.ProductOrderResourceIntTest > getProductOrder FAILED
    java.lang.AssertionError at ProductOrderResourceIntTest.java:229

com.mycompany.store.web.rest.ProductOrderResourceIntTest > getAllProductOrders FAILED
    java.lang.AssertionError at ProductOrderResourceIntTest.java:213

com.mycompany.store.web.rest.ProductOrderResourceIntTest > getNonExistingProductOrder FAILED
    java.lang.AssertionError at ProductOrderResourceIntTest.java:242

com.mycompany.store.web.rest.ShipmentResourceIntTest > getAllShipments FAILED
    java.lang.AssertionError at ShipmentResourceIntTest.java:176

com.mycompany.store.web.rest.ShipmentResourceIntTest > getShipment FAILED
    java.lang.AssertionError at ShipmentResourceIntTest.java:192

com.mycompany.store.web.rest.ShipmentResourceIntTest > getNonExistingShipment FAILED
    java.lang.AssertionError at ShipmentResourceIntTest.java:205

com.mycompany.store.web.rest.InvoiceResourceIntTest > getInvoice FAILED
    java.lang.AssertionError at InvoiceResourceIntTest.java:309

com.mycompany.store.web.rest.InvoiceResourceIntTest > getNonExistingInvoice FAILED
    java.lang.AssertionError at InvoiceResourceIntTest.java:326

com.mycompany.store.web.rest.InvoiceResourceIntTest > getAllInvoices FAILED
    java.lang.AssertionError at InvoiceResourceIntTest.java:289

com.mycompany.store.web.rest.OrderItemResourceIntTest > getNonExistingOrderItem FAILED
    java.lang.AssertionError at OrderItemResourceIntTest.java:247

com.mycompany.store.web.rest.OrderItemResourceIntTest > getAllOrderItems FAILED
    java.lang.AssertionError at OrderItemResourceIntTest.java:218

com.mycompany.store.web.rest.OrderItemResourceIntTest > getOrderItem FAILED
    java.lang.AssertionError at OrderItemResourceIntTest.java:234
2018-02-11 13:55:55.693 INFO 27458 --- [ Thread-10] c.m.store.config.CacheConfiguration : Closing Cache Manager

217 tests completed, 12 failed
You could also run the tests from your IDE so that you have a better error message and failure report. Select the entire src/test folder, right-click, and select Run all tests.
  1. These are expected to fail as we changed the Resource classes for these entities in the previous chapter to handle authorizations, and the failure means that it's working perfectly. Fortunately, it's not difficult to fix the tests using Spring. We can use the @WithMockUser annotation provided by the Spring test context to provide a mock user for our tests. Add the annotation with user details as highlighted in the following code to all the failing test classes:
@RunWith(SpringRunner.class)
@SpringBootTest(classes = StoreApp.class)
@WithMockUser(username="admin", authorities={"ROLE_ADMIN"}, password = "admin")
public class InvoiceResourceIntTest {
...
}
  1. We are providing a mock user with the ADMIN role here. Add the same to OrderItemResourceIntTest, ProductOrderResourceIntTest, and ShipmentResourceIntTest. Run the tests again and they should pass.
  2. Commit the changes made by running git commit -am "fix server side tests with mockUser".
  3. Now let's make sure our client-side Karma unit tests are working. Since we didn't make any logic changes on the client-side there shouldn't be any failures. Run the following command:
> yarn test
  1. All tests should pass. Let's head over to src/test/javascript/spec/app/entities/product/product.component.spec.ts. We use the Jasmine Framework for our tests. The existing test has the following structure. The beforeEach block sets up the Angular TestBed:
...

describe('Component Tests', () => {
    describe('Product Management Component', () => {
        ...
        beforeEach(() => {
            TestBed.configureTestingModule({
                ...
            })
            .overrideTemplate(ProductComponent, '')
            .compileComponents();
            ...
        });


        it('Should call load all on init', () => {
           ...
        });
        ...
    });

});
  1. Now let's make sure our protractor e2e tests are working. Run the following commands in two separate terminals. Start the server first. Let's clear the database as well by a running clean task so that tests run on a fresh setup. Since we are running a clean task we also need to run the webpackBuildDev task to rebuild the client side:
> ./gradlew clean webpackBuildDev bootRun
  1. Now run the e2e tests:
> yarn e2e
If you prefer not to run scripts via Yarn or NPM, you could also run them via Gradle using the node integration provided by JHipster. For example, instead of yarn e2e, you could run ./gradlew yarn_e2e, and instead of yarn test you could run ./gradlew yarn_test. This is useful if you do not want to install NodeJS and Yarn and want everything to be managed for you by Gradle. If you choose Maven instead of Gradle the same feature is available for that as well.
  1. All tests should pass here as well. But if you look at the generated e2e tests, for example, look at src/test/javascript/e2e/entities/customer.spec.ts, you will see that a test is commented out. Some tests are commented out during generation if an entity has a required relationship field, as we would have to create a relationship first and set its value for the test to work. Let's focus on only the Customer page test. Uncomment the test named should create and save Customers and change the describe function to fdescribe on the test file, so that only this test file is executed:
fdescribe('Customer e2e test', () => {
   ...
});
  1. Now execute yarn e2e and we should see one failing test. First, let's fix the email field by providing a valid email format:
    it('should create and save Customers', () => {
        ...
        customerDialogPage.setEmailInput('email@email.com');
        expect(customerDialogPage.getEmailInput()).toMatch('email@email.com');
        ...
    });
  1. Run yarn e2e again and this time it should pass. But since we have a one-to-one relationship between user and customer the test will fail if we run it again, hence we need to delete the row created after it. Let's add a test case for a delete action. In the CustomerComponentsPage class defined in the file (if you are using JHipster 5, this class will be available under src/test/javascript/e2e/page-objects/customer-page-object.ts), add a new property and methods as follows:
    table = element.all(by.css('.table-responsive tbody tr'));
    getTable() {
        return this.table;
    }

    deleteFirstItem() {
        this.table.first().element(by.css('button.btn-
        danger')).click();
    }
  1. Now add expect(customerComponentsPage.getTable().isPresent()).toBeTruthy(); as the last line in our previous test to confirm if the row was created. Then add the following test to delete the row:
it('should create and save Customers', () => {
        ...
        expect(customerComponentsPage.getTable().isPresent()).toBeTruthy();
    });

    it('should delete Customers', () => {
        customerComponentsPage.deleteFirstItem();
        const deleteBtn = element.all(by.css('.modal-footer 
        .btn.btn-danger'));
        deleteBtn.click();
        expect(customerComponentsPage.getTable().isPresent()).toBeFalsy();
    });
  1. Run yarn e2e again to verify. Do not forget to remove the fdescribe from the file so that all tests get executed. Congratulations! You added you first protractor e2e tests.
  2. Similarly, fix the commented out e2e tests in other files under src/test/javascript/e2e/entities as well. This is part of the next steps assignment.