Autogen per-test docs for discoverability
Mantenedores costumam responder em até 14 dias
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 5/5
- Tempo estimado
- Mais de uma semana
- Facilidade para iniciantes
- 25/100
- Tipo de issue
- Funcionalidade
- Clareza
- Precisa de esclarecimento
- Status de atividade
- Estagnada
- Stack de tecnologia
- go, yaml
- Domínio
- documentation, testing
Direção de pesquisa
Comece examinando o esquema YAML proposto e o ponto de entrada de exemplo tests/csapi/rooms_state_test.go:TestRoomCreationReportsEventsToMyself. Determine como sytests expõem nomes, comportamento, variantes e áreas de teste para a documentação automatizada. O trabalho estará concluído quando a documentação gerada puder listar esses detalhes e vincular cada entrada ao seu caminho de teste.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
While working on importing sytests, i found myself ctrl-shift-f-ing on keywords to see what tests already existed to see if a sytest would fit that file, however, I think that this displays some poor test discoverability.
However, when i was documenting some sytests (and their behaviour), i came upon something like the following format;
sytest:
- name: "Non-present room members cannot ban others"
type:
- power_level
- ban
desc:
When a user does not exist in a room, but has powerlevels there, it should not be able to ban users.
variants:
- user has never entered the room
- user has left the room
- user has been kicked while ban is sent out
- user server has been ACL-d
- name: "New federated private chats get full presence information (SYN-115)"
# ...
I think it would be useful to programmatically document (and maybe link) these tests, so that a quick glance can see which ones exist, what it does, what variants of behaviour it's also testing, and also in which "areas" of testing matrix it exists.
For a final variant of above schema, i think adding a path (something like tests/csapi/rooms_state_test.go:TestRoomCreationReportsEventsToMyself) would help auto-identify the corresponding function.
- Linguagem predominante
- Go
- Estrelas
- 101
- Forks
- 72
- Merge médio
- 11d 5h
- PRs com merge (30d)
- 7
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Tem um modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de matrix-org/complement
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
matrix-org/complement#900 · 1 comentário ·
Mantenedores costumam responder em até 14 dias
-
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 45/100
matrix-org/complement#938 ·
Mantenedores costumam responder em até 14 dias
-
New tests for MSC4354 Sticky EventsTalvez livre de novo @reivilibre assumiu há 33 dias e não há nenhum pull request aberto. Aberta
matrix-org/complement#925 · 1 responsável ·
Mantenedores costumam responder em até 14 dias
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 52/100
matrix-org/complement#901 · 1 comentário ·
Mantenedores costumam responder em até 14 dias
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 55/100
matrix-org/complement#899 ·
Mantenedores costumam responder em até 14 dias
Todas as issues de matrix-org/complement
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
containerd/containerd#14476 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
kind/bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
ome-projects/ome#1242 ·
Mantenedores costumam responder em até 1 dia
-
copy design-review mac P3
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 88/100
tosunlab/hisarapp-core#510 ·