bisakhmondal commented on a change in pull request #1625:
URL: https://github.com/apache/apisix-dashboard/pull/1625#discussion_r598224896



##########
File path: docs/en/latest/back-end-tests.md
##########
@@ -0,0 +1,98 @@
+---
+title: Backend Tests
+---
+
+<!--
+#
+# Licensed to the Apache Software Foundation (ASF) under one or more
+# contributor license agreements.  See the NOTICE file distributed with
+# this work for additional information regarding copyright ownership.
+# The ASF licenses this file to You under the Apache License, Version 2.0
+# (the "License"); you may not use this file except in compliance with
+# the License.  You may obtain a copy of the License at
+#
+#     http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+-->
+
+This document describes how to write unit tests & e2e tests for the backend.
+
+## Writing Unit Tests
+
+Currently, all of the unit tests for `manager-api` have been written using 
Go's built-in testing package. There is nothing new about it. You can directly 
add tests in the existing `<module>_test.go` file or create a new one. There is 
one thing that needs to be addressed that is, since `manager-api` largely 
depends on handling data from etcd, in some cases, you need to write some 
feature that depends on storing & retrieval of information on and out of etcd. 
In such a scenario, you should write your unit tests using 
`store.MockInterface` instead of directly depending upon etcd.
+
+The `MockInterface` embeds `mock.Mock` object from 
[mock](https://pkg.go.dev/github.com/stretchr/testify/mock) package by testify. 
If helps in simulating function calls of an object with desired inputs as 
arguments and outputs as return values. Currently, all the unit tests in 
`route`, `service`, `ssl` and `upstream` handlers uses mock interface. For eg.
+
+```go
+mStore := &store.MockInterface{}
+mStore.On("<exact methodname of the real method>", mock.Anything)
+      .Run(func(args mock.Arguments) {
+           //arguements assertions or anything
+           //gets executed before returning
+       })
+      .Return("<same return signature of the original method>")
+```
+
+You may tinker with the mentioned tests to get an idea of how it works or go 
through the 
[docs](https://pkg.go.dev/github.com/stretchr/testify/mock#pkg-index).
+
+## Writing E2E Tests
+
+Currently, the backend of apisix-dashboard have two types of e2e tests. One is 
plain e2e, the other is e2enew, where in the first one, tests are written using 
Go's built-in, native testing package, for the later, the tests are grouped 
into test suites and are evaluated using 
[ginkgo](https://onsi.github.io/ginkgo/) - a testing framework which helps in 
writing more expressive tests such that reading and writing tests give a 
pleasant experience.
+
+**Slowly, we are migrating all of our e2e tests to e2enew. So it is always 
recommended to write any new tests using ginkgo unless some situation arises. 
In such cases, please discuss your concerns with the community.
+
+For value assertion, we are using the 
[assert](https://pkg.go.dev/github.com/stretchr/[email protected]/assert) package 
by testify. It provides lots of easy to use functions for assertion where the 
first argument is   `*testing.T` object which you can obtain from the used 
framework for testing. For the built-in testing package, each test cases have 
this as the first argument of the test itself. For ginkgo `ginkgo.GinkgoT()` 
returns the mentioned object.
+
+If you are creating any test which requires making HTTP calls to any of the 
following node which involves `manager-api` or `apisix`, after setting up the 
environment (please refer [`backend-e2e.md`](./back-end-e2e.md) for the 
details), you can use the `HttpTestCase` struct which provides a nice interface 
to make the calls along with checking the response. Here's a brief description 
of the most used fields of the struct,
+
+```go
+type HttpTestCase struct {
+    Desc          string                // Description about the test case.
+    Object        *httpexpect.Expect    // returns a httpexpect object i.e. on 
which host the request is going to be made.
+    Method        string                // HTTP request methods ( GET, POST, 
PATCH, PUT, DELETE, OPTIONS).
+    Path          string                // the route path of that host
+    Query         string                // Query params
+    Body          string                // The request Body. Commonly used in 
POST, PUT, PATCH.
+    Headers       map[string]string     // Request headers. Include 
authorization header for secure routes.
+    ExpectStatus  int                   // Expected HTTP status code from the 
response
+    ExpectCode    int                   // Code generated by the host. 
Generally 0 for http.StatusOK.
+    ExpectMessage string                // The response message provided in 
the response by the host.
+    ExpectBody    interface{}           // The expected message body as a 
response.
+    Sleep         time.Duration //ms    // Cooldown period before making next 
request.
+}
+```
+
+Now to run a test use `RunTestCase(tc HttpTestCase)` or `testCaseCheck(tc 
HttpTestCase, t *testing.T)` for the `e2enew` or `e2e` respectively.

Review comment:
       Hii. I had added the note in line 
[48](https://github.com/apache/apisix-dashboard/pull/1625/files#diff-c6ae044f165581d7c8c5df0dac40b063a1461f412acf700ea02c65ed06faa176R47-R49).
 Would that be sufficient or should I add it here too explicitly?
   Thanks




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to