bzp2010 commented on code in PR #12179: URL: https://github.com/apache/apisix/pull/12179#discussion_r2063169415
########## 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: @membphis ~~This is insufficient for current testing, as the design does not share the configuration between workers in any way, but only broadcasts it through the event mechanism. Any restart of the worker may make the configuration disappear.~~ The test::nginx always uses reload or restarts the worker, which is bad. The current way is clear and runs entirely on a single instance, as it uses only one TEST section as a nutshell (which means the worker doesn't restart). > I know test::nginx allows no reload, but you can't modify the config because you don't want it to reload, and once you need to modify the config to add a new content_by_lua_block-like block, it has to reload. This makes it impossible to accurately assert tests with inline lua code, which is detrimental to the tests I'm working on. > Why do I have to use Lua: I want to check a rather complex nested data structure, and regular expressions can't do it simply, or aren't readable. Not to mention the fact that cjson simply can't guarantee stable key ordering in JSON. So I wanted to implement it using Lua assert until I realized the above problem. Another possible approach is to continue writing dirty shell scripts and treating them as cli tests, which requires us to check the response using similar external software such as jq or yq, which is also very bad. Very cumbersome and error prone. So I prefer to write these tests in [one of the most popular programming languages in the world](https://survey.stackoverflow.co/2024/technology#most-popular-technologies-language-prof), even typescript is far more popular to perl or shell, let alone javascript, | JavaScript | TypeScript | Bash/Shell | Perl | |------------|------------|------------|-------| | 64.6% | 43.4% | 34.2% | 2.3% | | | | | The era of Perl is over. | which allows us to take full advantage of the various libraries available for direct asserting, such as jest, yaml, or other libraries that are currently in use. This gives more people the opportunity to write tests without any confuses, rather than having to deal with strange test cases mixed with all sorts of weird perl, test::nginx scripts that are both hard to learn and hard to write. As a professional developer on APISIX, I too often have headaches because of this test framework. Further, this code won't be included in the release at all, it's just a few tests, which won't bother users in any way, and this won't lead to a runtime dependency on nodejs, so I think that's the best route to take. So, in the long-term, I'd like these ts-implemented tests to be first-class citizens, not stuffed into some folder. As a scripting language, js/ts is not fundamentally different from perl, anything that can be done with test::nginx can be done with them, even fine-grained manipulation of the nginx process for restart or reload, but it's just more popular, more modern, better ecologically, and it's time to embrace the future, if only for a little while. -- 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
