java - 是否可以使用“asterisk java”创建两个“asterisk”实例？

Question

我正在使用星号测试套件并创建自定义测试。但我正在尝试用 java 替换一些 python 脚本。

问题是我不知道如何使用“asterisk java”为每个使用自定义拨号计划创建两个星号实例。

Answer 1

好消息是，除了最上面的 run-tests.py 脚本之外，Asterisk 测试套件与语言无关。您会发现用 python、lua 甚至 bash 编写的测试。Java 将是一个新的补充。我不建议尝试重写 runtests.py - 你不会得到很多回报，尽管我想你可以这样做。

至于对 Asterisk 实例进行“沙盒化”，使其不会与其他 Asterisk 实例发生冲突，并且您可以同时运行任意数量，您必须采取许多步骤才能使其正常工作。幸运的是，如果您查看 asterisk.py 模块（在 lib/python/asterisk 中） - 或 asttest/lib/lua 中的 astlib.lua - 您将有一些工作示例，说明必须完成的所有工作发生。

至少，您需要执行以下操作：

• 创建将托管您的测试的目录结构。按照惯例，执行的每个测试都在 /tmp/asterisk-testsuite/[test_directory] ​​下运行，其中 [test_directory] ​​可能包含多个子目录，并且反映了该测试在测试套件中的位置。请注意，在测试失败的情况下，最顶部的脚本中有很多东西希望事物位于该相对位置，所以我不会从那里移动它。
• 在您的测试目录中创建与您要运行的 Asterisk 实例相对应的子文件夹。这些通常命名为 astn，其中 n 是该目录中的下一个可用数字。例如，假设您有两个在测试期间运行的 Asterisk 实例。第一次运行测试时，您将创建子目录 ast1 和 ast2。下一次; ast3 和 ast4。
• 对于要生成的每个 Asterisk 实例，创建一个 asterisk.conf 配置文件，该文件指定相对于前两个步骤中提到的位置，所有 Asterisk 配置目录的位置。然后您将创建的asterisk.conf '安装'到/tmp/asterisk-testsuite/[test_directory]/ast[n]/etc/asterisk/asterisk.conf。
• 安装其余所需的配置文件。如果测试不提供配置文件，python/lua 库所做的是硬链接到主机系统上检测到的配置文件；否则他们会将配置文件复制到这些目录中。
• 硬链接到系统上安装的模块。如果每个测试都有自定义模块，则可以将它们放在测试运行目录中。
• 当你生成 Asterisk 时，你指定一个不同的配置位置，而不是使用 -C 选项的默认位置。

例如，让我们以 confbridge python 测试为例。它生成了三个 Asterisk 实例。第一次运行时，它会退出并查看 /tmp/asterisk-testsuite 是否存在。可以说不是。所以我们创建了那个目录。

/tmp/asterisk-testsuite/

We then see that the test being run lives in tests/apps/confbridge - so we make our test directory, since we haven't run yet either.

/tmp/asterisk-testsuite/apps/confbridge

Now it gets interesting. We haven't run before, so when we check to see if any astn directories exist in our test directory, we determine that there aren't. So we create three of those directories.

/tmp/asterisk-testsuite/apps/confbridge
                                       /ast1
                                       /ast2
                                       /ast3

Taking only ast1 as an example, we create an asterisk.conf file containing locations to our paths:

[directories](!)
astetcdir => /tmp/asterisk-testsuite/apps/confbridge/ast1/etc/asterisk
astmoddir => /tmp/asterisk-testsuite/apps/confbridge/ast1/usr/lib/asterisk/modules
astvarlibdir => /tmp/asterisk-testsuite/apps/confbridge/ast1/var/lib/asterisk
astdbdir => /tmp/asterisk-testsuite/apps/confbridge/ast1/var/lib/asterisk
astkeydir => /tmp/asterisk-testsuite/apps/confbridge/ast1/var/lib/asterisk
astdatadir => /tmp/asterisk-testsuite/apps/confbridge/ast1/var/lib/asterisk
astagidir => /tmp/asterisk-testsuite/apps/confbridge/ast1/var/lib/asterisk/agi-bin
astspooldir => /tmp/asterisk-testsuite/apps/confbridge/ast1/var/spool/asterisk
astrundir => /tmp/asterisk-testsuite/apps/confbridge/ast1/var/run/asterisk
astlogdir => /tmp/asterisk-testsuite/apps/confbridge/ast1/var/log/asterisk

[options]
verbose = 5
debug = 5
defaultlanguage = en           ; Default language
documentation_language = en_US  ; Set the language you want documentation
                ; displayed in. Value is in the same format as
                ; locale names.   
[compat]
pbx_realtime=1.6
res_agi=1.6
app_set=1.6

We now copy our asterisk.conf into our test directory.

/tmp/asterisk-testsuite/apps/confbridge/ast1/etc/asterisk/asterisk.conf

We would then hardlink the necessary installed module shared objects to the /var/lib/asterisk/modules subdirectory, and hardlink the installed configuration files to the /etc/asterisk subdirectory. Alternatively, for /var/lib/asterisk/modules, we could have just let that use the standard installed modules and not done the hardlinking, if you so desire.

Finally, when we spawn Asterisk, we use the following syntax:

asterisk -f -g -q -m -n -C /tmp/asterisk-testsuite/apps/confbridge/ast1/etc/asterisk/asterisk.conf

Addendum to what I wrote above

There's nothing wrong with Java, but there's also a lot of re-inventing of the wheel you're going to have to do if you decide to go with a new language in the Test Suite - and not just in getting Asterisk spawned. We've written a lot of other stuff into the lua/python libraries that makes your life easier in addition to everything I've described here. Things like common test classes for CDR parsing and manipulation, voicemail manipulation, complex state machine interactions with SIPp, tests that harness multiple SIPp instances and orchestrate them in conjunction with the Test Suite - and we've been particularly focusing on the python libraries as of late. You may want to consider just going with Python - but, if you really love Java, by all means feel free to use that.