Por que testamos sempre em oito ambientes Linux diferentes

No Linux, dizer que algo “funciona” não é suficiente.

Até uma mesma versão do Ubuntu tem bibliotecas de sistema e toolkits diferentes conforme o lançamento. O modo de exibir a interface se divide entre X11 e Wayland, e para a entrada em coreano são usados ibus ou fcitx5. Quando acrescentamos também o formato de instalação, o número de combinações que precisam ser verificadas cresce rapidamente.

O fato de ter funcionado no computador de um desenvolvedor significa que apenas uma entre inúmeras combinações foi verificada.

Por isso, criei um pequeno laboratório dentro do repositório. Inicializo máquinas virtuais reais para cada ambiente e repito os mesmos testes. Os resultados são reunidos em uma única tabela.

O que a tabela verifica é simples.

O aplicativo abre? É possível digitar em coreano?

Nós vivenciamos primeiro os trinta segundos iniciais que o usuário terá depois de instalar o aplicativo.

Transformei cada ambiente em um único arquivo

O laboratório usa máquinas virtuais KVM em vez de contêineres. Isso porque é difícil reproduzir corretamente uma sessão de desktop real e o daemon do método de entrada usando contêineres.

Baixo a imagem de nuvem da distribuição e a preparo com cloud-init. O disco é criado como uma sobreposição sobre a imagem original. Se surgir algum problema, posso descartá-lo e começar novamente.

Cada ambiente é declarado em um único arquivo. O arquivo contém a distribuição, a imagem, a sessão, o método de entrada e os pacotes que serão instalados. Se quiser verificar uma nova combinação, basta adicionar um único arquivo.

A forma de inserir texto varia conforme a sessão. No X11, uso xdotool; no Wayland, uso ydotool. Como o Wayland não oferece uma lista de janelas, abro o aplicativo em tela cheia em um compositor de quiosque. Assim, é possível inserir texto sempre na mesma posição.

O aplicativo é compilado apenas uma vez no host. Em seguida, copio exatamente o mesmo binário para todas as máquinas virtuais.

Se ele fosse recompilado em cada ambiente, diferentes compiladores e bibliotecas se misturariam aos resultados. Quando ocorresse uma falha, seria mais difícil encontrar a causa. Acima de tudo, o arquivo recebido pelo usuário precisa ser o mesmo que o laboratório testa.

A máquina virtual testa, e o host registra

Dentro da máquina virtual, verifico três coisas.

Verifico se o binário é executado, se a janela aparece e se 안녕 surge ao digitar dkssud.

Cada teste deixa uma linha em JSON. O host reúne os resultados, salva-os em um arquivo e cria uma tabela. Os resultados medidos permanecem no repositório para serem comparados com os testes seguintes.

O método de verificação da entrada em coreano muda conforme o tipo de compilação. Na compilação de desenvolvimento, é possível verificar imediatamente os caracteres que estão sendo compostos. A compilação real para distribuição não tem esse recurso. Em vez disso, pressiono Enter, salvo o arquivo e depois leio o conteúdo gravado no disco.

Nesse processo, aprendi uma coisa. O que determinava o método de teste não era o formato de instalação, mas o tipo de compilação do aplicativo.

A primeira tabela revelou duas coisas

No Ubuntu 22.04, o aplicativo compilado com o toolkit do sistema não abria. Isso acontecia porque ele não conseguia encontrar um símbolo que existe apenas nas versões mais recentes da libadwaita.

Por outro lado, também confirmei pela primeira vez que a entrada em coreano funcionava normalmente com a combinação de Wayland e ibus.

Com base nesse resultado, decidi incluir o mesmo toolkit em todos os formatos de instalação. A atual tabela de oito linhas é uma proteção para verificar se essa decisão não voltou a ser quebrada.

Também houve problemas que só apareciam em ambientes reais. Ao contrário do Ubuntu para desktop, a imagem de nuvem não tinha o módulo de entrada GTK4 nem um modo de entrada inicial. Foi necessário instalá-los separadamente durante o processo de provisionamento.

O módulo do ibus precisava corresponder à versão do daemon instalada na distribuição. A forma de usar as ferramentas de entrada também variava entre as distribuições. Foi necessário separar os scripts de teste de acordo com o ambiente.

Para economizar a memória do host, executo no máximo duas máquinas virtuais simultaneamente. A máquina virtual é encerrada assim que seu resultado é recebido.

Todos esses eram problemas difíceis de encontrar apenas lendo o código. Isso porque o mesmo código produzia resultados diferentes conforme o ambiente. Foi por isso que precisei da tabela.

A tabela não promete desempenho

A tabela também registra o tempo necessário para exibir a primeira tela e o uso de memória. Mas não uso esses números como métricas de desempenho.

A máquina virtual renderiza a tela por software, sem GPU, e a medição é feita apenas uma vez, logo após a inicialização. Os valores podem variar a cada execução. O critério de desempenho é definido pela mediana de três medições feitas em um host com uma GPU real.

O que deve ser observado nessa tabela não são os milissegundos, mas as marcas de verificação.

Os ambientes que não pude verificar permanecem em branco. Fedora e Debian, sessões reais do GNOME e caixas de diálogo de portais, como a seleção de arquivos, ainda não estão na tabela.

Não preencho uma célula não verificada dizendo que “provavelmente vai funcionar”.

Não podemos determinar qual ambiente o usuário escolherá. O que podemos fazer é entrar primeiro nesse ambiente e tentar abrir o aplicativo.