---
title: 'TravisTorrent: exemplo'
author: "Rodrigo Rocha <rodrigo@dcc.ufba.br>"
date: "02/10/2016"
output: html_document
---

```{r setup, include=FALSE}
knitr::opts_chunk$set(echo = FALSE)
library(dplyr, warn.conflicts = FALSE)
library(pander, warn.conflicts = FALSE)

# Carrega os dados
builds <- readRDS('data/travis-sample.rds')
```

## Resumo

Os alunos do semestre 2017.1 da disciplina Engenharia de Software Experimental do PGCOMP-UFBA devem escrever um artigo curto no qual apresentarão uma análise qualitativa dos dados contidos no data set TravisTorrent, escolhido para o desafio da conferência Mining Software Repositories de 2017. Os alunos devem escrever o artigo no formato R Markdown, com o qual não estão completamente familiarizados. Com o objetivo de auxiliá-los nesse processo, este artigo fornece um exemplo de como escrever um artigo nos moldes do que foi exigido dos alunos. Espera-se com isso contribuir para que eles escrevam artigos de alta qualidade, demonstrando domínio do conteúdo das aulas.

## Preâmbulo

No decorrer de um curso de mestrado ou doutorado, espera-se que os alunos desenvolvam pesquisa relevante em suas respectivas áreas e demonstrem domínio de ferramentas adequadas para validar os resultados de suas pesquisas. Uma ferramenta importante nesse contexto é a análise quantitativa, que engloba abordagens como estatística descritiva, estatística inferencial e visualização de dados.

Experiências anteriormente vivenciadas pelo autor sugerem que o conhecimento teórico das ferramentas de análise de dados, embora necessário, é insuficiente para que os alunos realizem análises de forma produtiva em suas pesquisas. As evidências sugerem que o domínio de sistemas de software específicos para análise de dados é igualmente importante para viabilizar o uso prático das abordagens.

Por essa razão, neste artigo propomos o ensino da linguagem de programação R simultaneamente ao ensino de conceitos de análise de dados, e a avaliação conjunta dos dois conteúdos a partir de uma atividade prática de escrita de artigos de análise de dados usando a linguagem R. Mais especificamente, propomos como atividade avaliativa a escrita de um artigo no formato [R Markdown](http://rmarkdown.rstudio.com/) a partir da análise de dados do data set [TravisTorrent](https://travistorrent.testroots.org/), disponibilizado no [MSR Challenge 2017](https://2017.msrconf.org/#/challenge), um desafio público de análise de dados.

Considerando a pouca experiência dos alunos com análise quantitativa, com a linguagem R e com o formato R Markdown, este artigo fornece um exemplo simples de artigo que usa o data set TravisTorrent e as ferramentas de análise quantitativa.

## Introdução

<!-- Contexto -->
Testes automatizados são importantes porque... Em projetos que adotam integração contínua, testes automatizados podem ser executados cada vez que um desenvolvedor publica mudanças no código-fonte de um projeto...

<!-- Lacuna no conhecimento -->
Há poucos estudos sobre...

<!-- Questões de pesquisa -->
Com o objetivo de compreender melhor..., neste estudo investigamos duas questões de pesquisa:

- RQ1. Quantos testes são executados por build em projetos que adotam integração contínua?
- RQ2. Existe diferença na quantidade de testes executados por build em projetos escritos em Java e em Ruby?

## Metodologia

<!-- Dados -->

Para responder às questões de pesquisa, utilizamos o data set [TravisTorrent](https://travistorrent.testroots.org/) disponibilizado no [MSR Challenge 2017](https://2017.msrconf.org/#/challenge), que contém dados extraídos do GitHub e do TravisTorrent sobre mais de mil projetos desenvolvidos em duas linguagens, Ruby e Java.

```{r}
projetos <- builds %>%
  group_by(gh_project_name) %>%
  summarise(num_builds = n())

linguagens <- builds %>%
  group_by(gh_lang) %>%
  summarise(num_builds = n(),
            num_projetos = n_distinct(gh_project_name))

num_projetos_java <- linguagens %>%
  filter(gh_lang == 'java') %>%
  select(num_projetos)

num_projetos_ruby <- linguagens %>%
  filter(gh_lang == 'ruby') %>%
  select(num_projetos)
```

<!-- Transformação -->
Para responder às questões de pesquisa, selecionamos uma amostra aleatória de `r nrow(projetos)` projetos, sendo `r num_projetos_java` projetos em Java e `r num_projetos_ruby` projetos em Ruby.

Para cada build job, consideramos o número de testes executados, reportado no campo `tr_log_num_tests_run` do data set...

<!-- Análise -->
Para a RQ1... histograma...

Para a RQ2... boxplot... teste de Wilcoxon pareado...

## Resultados

(adaptado do artigo ["Oops, my tests broke the build: An analysis of Travis CI builds with GitHub"](https://peerj.com/preprints/1984/), Seção 4.2, para fins didáticos)

**RQ1. Quantos testes são executados por build em projetos que adotam integração contínua?** A Figura 1 apresenta um histograma do número de testes executados por build. Como esperado, o histograma segue uma distribuição próxima à distribuição power-law frequentemente observada em estudos empíricos: a maioria dos projetos executa uma quantidade menor de testes, enquanto alguns executam muitos testes (média: `r mean(builds$tr_log_num_tests_run, na.rm=T)`; mediana: `r median(builds$tr_log_num_tests_run, na.rm=T)`; 95%: `r quantile(builds$tr_log_num_tests_run, 0.95, na.rm=T)`).

```{r fig.cap="**Figura 1**. Número de testes por build por linguagem (escala logarítmica)."}
hist(builds$tr_log_num_tests_run, ylab="Número de builds", main="", xlab="")
```

```{r}
mediana_execucoes_testes <- builds %>%
  group_by(gh_lang) %>%
  summarise(med_tests_run = median(tr_log_num_tests_run, na.rm=T))
```

**RQ2. Existe diferença na quantidade de testes executados por build em projetos escritos em Java e em Ruby?** A Figura 2 mostra a distribuição de execuções de testes na duas linguagens da nossa amostra, em escala logarítmica; o gráfico revela que builds de projetos Ruby tendem a executar mais testes (mediana: `r filter(mediana_execucoes_testes, gh_lang == 'ruby')$med_tests_run`) que builds de projetos Java (mediana: `r filter(mediana_execucoes_testes, gh_lang == 'java')$med_tests_run`). A diferença é estatisticamente significativa para um nível de confiança de 95% de acordo com o teste de Wilcoxon pareado.

```{r fig.cap="**Figura 2**. Número de testes executados por build (escala logarítmica)."}
# adiciona 1 para evitar problemas com 0 na escala logaritmica
builds_mais1 <- builds %>% mutate(tr_log_num_tests_run = tr_log_num_tests_run + 1)
boxplot(tr_log_num_tests_run ~ gh_lang, data=builds_mais1, log="y", ylab="Testes executados (escala logarítmica)")
```

```{r}
p <- wilcox.test(tr_log_num_tests_run ~ gh_lang, data=builds)$p.value
stopifnot(p < 0.05) # dá erro se diferença não for estatisticamente significativa
```

Uma possível explicação para a diferença observada é que, pelo fato de Java ser uma linguagem compilada e estaticamente tipificada, muitos erros de codificação são detectados em tempo de compilação, dispensando a criação de certos testes de unidade. Outro fator que pode explicar a diferença é a existência de uma forte cultura de testes na comunidade Ruby; aplicações escritas em Rails, o framework web mais popular para Ruby, são comumente escritas com o auxílio de geradores de código que produzem código para uma funcionalidade acompanhado de testes. Estudos adicionais são necessários para validar essas hipóteses, com o uso de diferentes linguagens de programação.

## Conclusão

Neste estudo, descobrimos que... Os resultados mostram que...

Uma limitação do trabalho é que todos os projetos analisados são open source e hospedados no GitHub... Os resultados podem não ser generalizáveis para outros contextos...

Como trabalho futuro, pretendemos...

------------

### Links relevantes

Links sobre R:

- [R Markdown](http://rmarkdown.rstudio.com/) (excelente guia de referência sobre o formato R Markdown)
- [Try R](http://tryr.codeschool.com/) (tutorial interativo)
- [Quick-R](http://statmethods.net/) (site com material de referência)
- [The Art of R Programming](http://heather.cs.ucdavis.edu/~matloff/132/NSPpart.pdf) (livro sobre R como linguagem de programação)
- [R in Action](https://www.manning.com/books/r-in-action-second-edition) (livro do autor do site Quick-R)

Links sobre o data set TravisTorrent:

- [MSR Challenge 2017](http://2017.msrconf.org/#/challenge) (página do evento)
- [TravisTorrent: Synthesizing Travis CI and GitHub for Full-Stack Research on Continuous Integration](http://inventitech.com/publications/2017_beller_gousios_zaidman_travistorrent_synthesizing_travis_ci_and_github_for_full-stack_research_on_continuous_integration.pdf) (descrição do data set)
- [Oops, my tests broke the build: An analysis of Travis CI builds with GitHub](https://peerj.com/preprints/1984.pdf) (exemplo de análise com o data set)
- [TravisTorrent](https://travistorrent.testroots.org/) (outras informações sobre o data set)
- [Amostra do data set com 100 projetos](https://github.com/rodrigorgs/analise-quantitativa/blob/master/data/travis-sample.rds) (data set a ser usado na disciplina)


```{r}
# % de builds bem sucedidas por linguagem

x <- builds %>%
  group_by(gh_project_name, gh_lang) %>%
  summarise(p_sucesso = mean(tr_status == 'passed'))

x <- builds %>%
  group_by(gh_project_name) %>%
  summarise(num_modifs_doc = sum(gh_diff_doc_files >= 1))


```
