Skip to main content

Guidelines for Testing

Image
By

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

By
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...
149 comments
Read more

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

By
  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
Post a Comment
Read more

Logging in AWS lambda

By
Problem : Logs are very important aspect of any microservice or any AWS service and in AWS if your rate of generating Cloudwatch logs is high ,then  it can increase your AWS costs significantly. There should be some limit on the growth of the logs to keep costs under control. Solution : There are multiple ways to manage the logging. Let's begin with some of the best practices and then some framework level changes which can help in reducing the overall logging. Best Practices : 1. Most of the times we are only interested to find error scenarios from the logs so it is important to use log.error while logging error cases. Never use other logging levels for logging errors 2. Never use print statements instead use a proper logging framework to log the statements 2. Be diligent about the log statements and categorize them correctly at different log levels : DEBUG , INFO , ERROR 4. Don't log data unless there is a critical need for same. Eve...
Post a Comment
Read more