Moving towards better and more cohesive tests descriptions.

[bidoubiwa]

In all (or almost all) the integrations that we maintain, we have tests covering the code.
These tests are all described by a small text explaining what they test.

Currently, the wording of these descriptions is up to the person adding the tests, resulting in a lack of consistency in how we word tests.

One person (me for example) can describe tests in multiple different ways even in a same repo. Per the broken window theory, because we do not follow a proper guideline for our tests description we do not encourage contributors or teammates to be clean and cohesive in their tests description.

The idea of this issue is to find resources and agree upon a test description style we like. They might be different for each language based on possibilities but also their best practices.

• Rails/Ruby: As per this comment, a possibility is to follow the guidelines of betterSpec.

[brunoocasali]

We also could add this: http://xunitpatterns.com/Four%20Phase%20Test.html which is a good practice to follow.

[bidoubiwa]

I like it alot

   NonTxFlightMngtFacade facade = new NonTxFlightMngtFacade();
   private BigDecimal airportId;
  
   protected void setUp() throws Exception {
      // Fixture setup
      super.setUp();
      airportId = facade.createTestAirport("1OF");
   }
   
   public void testGetFlightsByOriginAirport_NoFlights_implicit() throws Exception {
      // Exercise SUT
      List flightsAtDestination1 = facade.getFlightsByOriginAirport(airportId);
      // Verify Outcome
      assertEquals( 0, flightsAtDestination1.size() );
   }   
  
   protected void tearDown() throws Exception {
      // Fixture teardown
      facade.removeAirport(airportId);
      super.tearDown();
   }
Example FourPhaseTestImplicit embedded from java

I think we should also find a better way to name the tests

[brunoocasali]

This could be something we could follow for e2e testing: https://docs.cypress.io/guides/references/best-practices

[brunoocasali]

We should always take the direction to write better code and tests, but this issue has a broader and too big scope to be prioritized anytime. So I'll close this.