[GitHub] [trafficcontrol] ocket8888 commented on a change in pull request #3478: Mock Traffic Ops Server

[GitBox <gi...@apache.org>]

ocket8888 commented on a change in pull request #3478: Mock Traffic Ops Server
URL: https://github.com/apache/trafficcontrol/pull/3478#discussion_r274998445
 
 

 ##########
 File path: traffic_ops/client_tests/cachegroups.go
 ##########
 @@ -0,0 +1,99 @@
+package main
+
+/*
+ * 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.
+ */
+import "net/http"
+
+import "github.com/apache/trafficcontrol/lib/go-tc"
+import "github.com/apache/trafficcontrol/traffic_ops/traffic_ops_golang/api"
+
+// Static Cache Group fields
+var EDGE_CACHEGROUP_ID = 1
+var EDGE_CACHEGROUP = "Edge"
+var EDGE_CACHEGROUP_SHORT_NAME = "Edge"
+var EDGE_CACHEGROUP_LATITUDE = 0.0
+var EDGE_CACHEGROUP_LONGITUDE = 0.0
+var EDGE_CACHEGROUP_PARENT_NAME = "Mid" // NOTE: This places a hard requirement on the `cachegroups` implementation - must have a `MID_LOC` Cache Group named "Mid"
+var EDGE_CACHEGROUP_PARENT_ID = 2       // NOTE: This places a hard requirement on the `cachegroups` implementation - must have a `MID_LOC` Cache Group identified by `2`
+var EDGE_CACHEGROUP_FALLBACK_TO_CLOSEST = true
+var EDGE_CACHEGROUP_LOCALIZATION_METHODS = []tc.LocalizationMethod{
+	tc.LocalizationMethodCZ,
+	tc.LocalizationMethodDeepCZ,
+	tc.LocalizationMethodGeo,
+}
+
+var MID_CACHEGROUP_ID = 2
+var MID_CACHEGROUP = "Mid"
+var MID_CACHEGROUP_SHORT_NAME = "Mid"
+var MID_CACHEGROUP_LATITUDE = 0.0
+var MID_CACHEGROUP_LONGITUDE = 0.0
+var MID_CACHEGROUP_FALLBACK_TO_CLOSEST = true
+var MID_CACHEGROUP_LOCALIZATION_METHODS = []tc.LocalizationMethod{
+	tc.LocalizationMethodCZ,
+	tc.LocalizationMethodDeepCZ,
+	tc.LocalizationMethodGeo,
+}
+
+var CACHEGROUPS = []tc.CacheGroupNullable{
 
 Review comment:
   Some of that behavior can lead to invalid or self-inconsistent fields, like `Type: "asdfg",` and `Latitude: 400.6`. We could make constraints by field, but at some point that becomes more complex than defining static defaults - and with essentially the same effect. Plus, making it dynamic/random could harm testability. At the least, I want this thing to be able to be used for tests of ORT, and that means it's beneficial to have static configfile output. But if profile/server/cdn names/ids and associated parameter names/ids/values/locations are random/dynamic then they could conflict with the static output of the configfiles. I don't think that's a problem today, but setting up a self-inconsistent testing environment seems like a bad idea to me. In order to make that deterministic, we'd need to build configfile generation logic into the mock server to be maintained separately from TO's configfile generation logic, and probably do the same for any tests using the mock server.
   
   It's unfortunate because I share your concern about maintaining structure twice, but this seems like the lesser of the two evils, and less work to maintain.

----------------------------------------------------------------
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:
users@infra.apache.org


With regards,
Apache Git Services