bzp2010 commented on code in PR #12179: URL: https://github.com/apache/apisix/pull/12179#discussion_r2068140418
########## t/admin/standalone.spec.ts: ########## @@ -0,0 +1,232 @@ +/* + * 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 axios from "axios"; +import YAML from "yaml"; + +const config1 = { + routes: [ + { + id: "r1", + uri: "/r1", + upstream: { + nodes: { "127.0.0.1:1980": 1 }, + type: "roundrobin", + }, + plugins: { "proxy-rewrite": { uri: "/hello" } }, + }, + ], +}; +const config2 = { + routes: [ + { + id: "r2", + uri: "/r2", + upstream: { + nodes: { "127.0.0.1:1980": 1 }, + type: "roundrobin", + }, + plugins: { "proxy-rewrite": { uri: "/hello" } }, + }, + ], +}; +const clientConfig = { + baseURL: "http://localhost:1984";, + headers: { + "X-API-KEY": "edd1c9f034335f136f87ad84b625c8f1", + }, +}; + +describe("Admin - Standalone", () => { Review Comment: @AlinsRan Technically, I've already explained the extent to which test::nginx doesn't meet my needs: the rigid perl DSL doesn't allow me to fine-tune the response data checker without introducing and learning new dependencies, and the use of content_by_lua blocks means that this forcefully couples the testing process with openresty's reload or restart, which would largely break the shared memory or event broadcast mechanism. Instead of wasting time on things like Perl or test::nginx (which even implements an HTTP protocol parser of its own, why?), it's better to find another way out. These tests can be based on any language, even with the efficient but primitive Go. Introducing new testing tools is all about solving ease-of-use and efficiency problems, which are not helped by using technologies with poor expressiveness (forced typing and barren standard libraries) and such a poor audience (two times as many professional developers use Java as use Go, three times as many professional developers use TypeScript as use Go, and four times as many professional developers use JavaScript as use Go). > If we want to write new test cases, should we consider using test-nginx or JavaScript? There is no clear policy about it, and developers choose familiar technologies to complete their tests. This is not mandatory. Right now, these new test sets don't have explicit internal APIs for things like modifying configurations, reloading, or restarting openresty, so they're lightweight and focused on testing APISIX for functional modifications using HTTP clients. Some of the more complex features can be introduced incrementally to allow us to implement more varied tests on nodejs until it is ready for the full range of professional developers' testing needs. At that point, we will consider stopping accept new tests using test::nginx. As such, there is no risk of any immediate deprecation, and tests that already use test::nginx will continue to exist until they are rewritten more appropriately (if one so desires). > I am more inclined towards one of them, which is that introducing more language ecosystems actually increases complexity. Continuing to invest in technologies that are outdated and hold no promise for development will cause us to accumulate more technical debt and get stuck in a quagmire. The use of new technologies will bring efficiency gains and greatly increase the number of engineers capable of developing APISIX functionality, and TypeScript is a technology that stands at the right balance of efficiency, maintainability, and adoption. I think the advantages will outweigh the disadvantages in terms of complexity, and the test framework will be implemented and maintained in the APISIX project so that users will only have to focus on how to write tests and not waste time exploring the boundaries of test::nginx functionality and debugging the odd glitch there (I've had enough of this). Many features have more standard implementations, and the myriad of dependency libraries will support features that are not in the standard library. None of these are easily solved by Perl or test::nginx which is only a subset of the functionality, and with engineers being forced to learn it or quit APISIX development, I think the choice of which is simpler is obvious. --- **I don't want to try to solve these problems in-system, which have already been stomped into the dust by other technologies. I don't want to waste my time with technologies that have been buried up to their necks in dirt.** Although I can write code fluently consisting of test::nginx and solve any new problems I encounter. But I don't want to waste any more minutes on this mentally torturous ancient technology. --- cc @membphis -- 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. To unsubscribe, e-mail: notifications-unsubscr...@apisix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
