Verifying server-side routing and template rendering

We created a test to verify all the server-side routes of the IGWEB application. Each route that we test will be associated with an expected string token, which is rendered in the page response, particularly in the primary content div container. So, not only will we be able to verify if the server-side route is functioning properly or not, but we will also know if the server-side template rendering is functioning normally.

Here are the contents of the routes_test.go source file, found in the tests folder:

package tests

import (
"io/ioutil"
"net/http"
"strings"
"testing"
)

func checkRoute(t *testing.T, route string, expectedToken string) {

testURL := testHost + route
response, err := http.Get(testURL)
if err != nil {
t.Errorf("Could not connect to URL: %s. Failed with error: %s",
testURL, err)
} else {
defer response.Body.Close()
contents, err := ioutil.ReadAll(response.Body)
if err != nil {
t.Errorf("Could not read response body. Failed with error: %s",
err)
}
if strings.Contains(string(contents), expectedToken) == false {
t.Errorf("Could not find expected string token: "%s", in
response body for URL: %s", expectedToken, testURL)
}
}
}

func TestServerSideRoutes(t *testing.T) {

routesTokenMap := map[string]string{"": "IGWEB", "/": "IGWEB",
"/index": "IGWEB", "/products": "Add To Cart", "/product-
detail/swiss-army-knife": "Swiss Army Knife", "/about": "Molly",
"/contact": "Enter your message for us here"}

for route, expectedString := range routesTokenMap {
checkRoute(t, route, expectedString)
}
}

The testHost variable that we defined, is used to specify the hostname and port where the IGWEB instance is running.

The TestServerSideRoutes function is responsible for testing server-side routes, and verifying that the expected token string exists within the response body. Inside the function, we declare and initialize the routesTokenMap variable of type map[string]string. The keys in this map, represent the server-side route that we are testing, and the value for a given key, represents the expected string token that should exist in the web page response returned from the server. So, this test not only will tell us if the server-side route is functioning properly, but it will also give us a good idea on the health of template rendering, since the expected string tokens we supply are all strings that should be found in the body of the web page. We then range through the routesTokenMap, and for each iteration, we pass in the route and the expectedString to the checkRoute function.

The checkRoute function is responsible for accessing a given route, reading its response body and verifying that the expectedString exists within the response body. There are three conditions that can cause the test to fail:

  1. When a connection to the route URL cannot be made
  2. If the response body retrieved from the server could not be read
  3. If the expected string token did not exist in the web page response returned from the server

If any of these three errors occur, the test will fail. Otherwise the function will return normally.

We can run this test by issuing the following go test command:

$ go test -run TestServerSideRoutes

Examining the output of running the test shows that the test has passed:

$ go test -run TestServerSideRoutes
PASS
ok github.com/EngineerKamesh/igb/igweb/tests 0.014s

We have now successfully verified accessing server-side routes and ensuring that the expected string in each route was rendered properly in the web page response. Now, let's start verifying the contact form functionality, starting with the form validation functionality.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.216.117.191