Skip to main content

Guidelines for Testing

Below are few guidelines which can be followed by testing team while working in a CI-CD environment. 



Jenkins :

  • Any tests which run on the latest version of the code should be scheduled to be triggered from the latest dev checkin.
  • Any tests which run against the QA environment should be triggered based on a schedule
  • Tests should be set up to run on our single server .
  • Once you have added your test to jenkins, don't ignore it. Keep an eye on it. If a build has suddenly turned red, either raise a bug or if it is failing due to compilation error / other reason work to fix the test. 
  • All builds must have a ReportNG report linked on the front page

 


SVN :
  • Rather than updating one file at a time, make sure that you update the full project in order to avoid missing files or changes
  • Likewise don't commit one file at a time as small changes in other classes / config files can be easily missed
  • After you have checked in, check the related builds in Jenkins for any compile errors or new test failures - even if it has run ok locally, other peoples checkins might interfere



Writing test cases in Java :

  • Ensure that all tests are given a meaningful name, that makes it clear what is being tested in a method. E.g. noNullPrices() rather than testPrices()
  • Use TestNG rather than JUnit
  • camelCase() for method names and variables
  • no underscores _
  • Method and class names should be descriptive.
  • Avoid relying on System.out.println. This fills up logs. If a test has passed, this will never be looked at. If at test has failed, it is better to create a report and link to it from jenkins.
  • Every test must be added to a testsuite which is scheduled in jenkins. A test which is not running is useless!
  • If you have any code which is reusable, add it to the CommonFramework - e.g. reading files
  • NEVER comment out someone else's code - if it causes you compile errors, check with team
  • Avoid commenting lines out. Just remove them. SVN gives us the ability to retrieve old versions.

Comments

Post a Comment

Popular posts from this blog

Extent report plugin for cucumber framework

Extent Reports  are the most popular  reporting  used with Selenium. ExtentReport API makes our life easy to generate interactive  report  with simple configuartions. It supports almost all Java and .NET test frameworks such as TestNG , JUnit , NUnit etc Here we are discussing about  a plugin which is build on  Extent Report specially for Cucumber. This plugin is used to simple out the implementation of  Extent Report  in  Cucumber Framework .  We are creating a maven project to implement the integration of our plugin with cucumber 1. Create new maven project in any tool eclipse/sts/intellij 2. Open pom.xml and update below entries. Step 1 : Add Cucumber Extent Reporter library to Maven Project Add  cucumber-extentsreport <dependency>      <groupId> com.vimalselvam </groupId>      <artifactId> cucumber-extentsreport </artif...

java: You aren't using a compiler supported by lombok, so lombok will not work and has been disabled.

  In order to make projects compile with the existing builds of Lombok processor, as a workaround you can use the flag -Djps.track.ap.dependencies=false which should be added to File | Settings | Build, Execution, Deployment | Compiler | Build process VM options field. This will disable collection of dependencies specified by an annotation processor when Filer methods are called

Execution default of goal org.springframework.boot:spring-boot-maven-plugin:1.2.3.RELEASE:repackage failed: Unable to find main class

Solutions:  Solution 1 : You needed to change the packaging parameter to jar from pom. Also, the repositories , pluginRepositories , the maven-compiler-plugin and the spring-boot-maven-plugin's version and executions weren't needed. Solution 2:  Try mvn install and see if it works Solution 3: Preview: <properties> <!-- The main class to start by executing java -jar --> <start-class> com.mycorp.starter.HelloWorldApplication </start-class> </properties> Solution 4: Enable the main() method in your Application.java. Configure spring-boot-maven-plugin to specify the class with the main class (Spring should find it anyway if you have one, but good to be explicit): Preview: <plugin> <groupId> org.springframework.boot </groupId> <artifactId> spring-boot-maven-plugin </artifactId> <version> ${spring-boot-version} </version>...