Refatoração, Reusabilidade e Extensão

[mestihudson]

Senhores,

"estudando" a classe CommonSteps percebo que a mesma tem crescido bastante, o que por si só já sugere uma refatoração.

Posto isso, observo que a mesma tem acumulado responsabilidades, visto que, a princípio, uma classe desse tipo tem características de Delegate, Proxy ou Facade, mas tem realizado atividades típicas de uma Factory e Helper, para atender as necessidades relacionadas aos PageObjects.

Relendo o slide do @botelhojp, observei, na página 3 (item 2), que o dbehave, prevê o uso de suítes variadas, tais como: jbehave, cucumber e concordion, e atualmente só existe implementação para o primeiro.

Penso ainda que, no coração do demoiselle-behave estão, exatamente, as facilidades implementadas na infraestrutura utilizada nos métodos da classe citada, pois essa resolve uma série de problemas que se tem ao utilizar o selenium ou fest.

Bem, quero propor uma refatoração no CommonSteps para que as ações nele executadas possam ser reutilizadas por outras suítes.

Tenho trabalhado na implementação dos arquétipos: cucumber-selenium e concordion-selenium (posteriormente extensíveis para cucumber-fest e concordian-fest), mas tenho esbarrado na replicação dessas implementações.

Também receio investir muito tempo em algo para depois não ser aceito pelo core-team.

Aguardo retorno.

[botelhojp]

@mestihudson, propostas de melhoria são muito bem bem-vindas, obviamente nem todas podem ser aceitas ou implementadas. Precisamos avaliar riscos de quebra, retrocompatibilidades, manutenibilidade e principalmente o valor agregado que ela trará.

Gostaria que especificasse melhor a proposta, pois não entendi como a refatoração na classe CommoSteps facilitaria a criação de novos parsers (cucumber-selenium e concordion-selenium). A classe CommoSteps encontra-se no parser do JBehave e não deve ser reutilizada para outros fins.

Se você pretende criar parsers eles devem ser feitos de forma independente da implementação do parser-jbehave. Outra questão a se pensar é o valor agregado de novos parsers, uma vez, que temos uma base expressiva em JBehave.

[mestihudson]

@botelhojp, "veja bem", em nenhum momento eu falei em alteração do Parser [1], minha proposta é retirar a responsabilidade de helper de dentro do CommonSteps e colocar em uma classe helper.UI:
Hoje,

public class CommonSteps implements Step {
  ...
  @Given("vou para a tela \"$local\"")
  @Then("vou para a tela \"$local\"")
  @When("vou para a tela \"$local\"")
  public void goToWithName(String local) {
    logger.debug("Go to screen " + local);
    currentPageName = local;
    String url = ReflectionUtil.getLocation(local);
    runner.navigateTo(url);
  }

  @Given("estou na tela \"$local\"")
  @Then("estou na tela \"$local\"")
  @When("estou na tela \"$local\"")
  public void pageWithName(String local) {
    logger.debug("Setting screen " + local);
    currentPageName = local;
    runner.setScreen(local);
  }
  ...
}

Proposta,

public class CommonSteps implements Step {
  ...
  @Given("vou para a tela \"$local\"")
  @Then("vou para a tela \"$local\"")
  @When("vou para a tela \"$local\"")
  public void goToWithName(String local) {
    UI.page(local).go();
  }

  @Given("estou na tela \"$local\"")
  @Then("estou na tela \"$local\"")
  @When("estou na tela \"$local\"")
  public void pageWithName(String local) {
    UI.page(local);
  }
  ...
}

package **.helper.UI;

public class UI {
  private static UI instance = ...;
  ...
  public static UI go() {
    logger.debug("Go to screen " + currentPageName);
    String url = ReflectionUtil.getLocation(currentPageName);
    runner.navigateTo(url);
    return instance;
  }

  public static UI go(String local) {
    UI.page(local).go();
    return instance;
  }

  public static UI page(String local) {
    logger.debug("Setting screen " + local);
    currentPageName = local;
    runner.setScreen(local);
    return instance;
  }
  ...
}

Isso permitiria, por exemplo, ao criar uma classe de Steps para Cucumber [2] ou Concordion [3], reutilizando a implementação dos métodos de CommonSteps, uma vez que os mecanismos de glue dos frameworks é diferente.

[1] Ainda considerando que, mesmo agregando valor, a reutilização sugerida/permitida por ele, incentiva uma prática que dificulta, ou impede, a repetibilidade do cenário/teste e, não raras vezes, contribui para a pouca legibilidade do mesmo. Mas, também, considero que o que não me atrapalha, também me ajuda, por exemplo, nos projetos que participo, não * recomendo * a reutilização de cenários, conforme estendida pelo DBehave, pelos motivos expostos (vividos na prática), e apresento alternativas plausíveis.
[2]

public class CucumberCommonSteps {
  ...
  @Dado("^que vou para a tela \"([^\"]*)\"$")
  @Quando("^vou para a tela \"([^\"]*)\"$")
  @Então("^vou para a tela \"([^\"]*)\"$")
  public void goToWithName(String local) throws Throwable {
    UI.page(local).go();
  }

  @Dado("^que estou na tela \"([^\"]*)\"$")
  @Quando("^estou na tela \"([^\"]*)\"$")
  @Então("^estou na tela \"([^\"]*)\"$")
  public void pageWithName(String local) {
    UI.page(local);
  }
}

[3]

public abstract class ConcordionCommonSteps {
  ...
  public void goToWithName(String local) throws Throwable {
    UI.page(local).go();
  }

  public void pageWithName(String local) {
    UI.page(local);
  }
}

[botelhojp]

Agora entendi melhor a questão. Portanto te faço uma proposta: antes da refatoração desejada, recomendo que implemente um novo parse, para termos mais segurança quantos aos pontos que precisam ser melhorados para a criação de novos parses.

Pessoalmente, tenho apreço pelo concordion e gostaria de vê-lo como uma alternativa do dbehave. Sugiro que crie um projeto no github chamado demoiselle-behave-parser-concordion e faça as implementações identificando as necessidades de refatoração.

Como sua proposta trata de refatoração, entendo que o único prejuízo do projeto proposto (concordion), serão as possíveis redundâncias, mas que não impedirão sua construção.

Quando tivermos dois parsers implementados, poderemos ver com mais facilidade os pontos de refatoração e consequentemente uma melhor massa crítica para tomar esta decisão.

[rogernobre]

@mestihudson, desculpe mas não entendi a parte "[1]: não * recomendo * a reutilização de cenários, conforme estendida pelo DBehave, pelos motivos expostos (vividos na prática), e apresento alternativas plausíveis." Como seria a sua sugestão de reutilização de cenários ou a não reutilização de cenários?

[rogernobre]

@mestihudson, por favor faça um pull request somente com uma implementação de algum parse, para que aqui, todos possam ter a mesma ideia sugerida.

[mestihudson]

@rogernobre, acredito que EU não esteja conseguindo me fazer entender (é um problema de comunicação, exclusivamente, MEU), portanto prefiro que marquemos uma conversa em um outro fórum de discussão pois o "papel" aceita qualquer coisa, menos as emoções envolvidas, o que pode transparecer, às vezes, que uma expressão foi colocada com uma intenção ao invés de outra. Essa semana já está finalizando, mas podemos organizar algo para a próxima.

[fgsl]

@mestihudson, houve algum progresso nessa proposta? Ela foi implementada em algum repositório, conforme #issuecomment-61258998?