Java Coding Convention

http://yohanan.org/steve/projects/java-code-conventions/

1. Use short enough and long enough variable names in each scope of code. Generally length may be 1 char for loop counters, 1 word for condition/loop variables, 1-2 words for methods, 2-3 words for classes, 3-4 words for globals.
2. Use specific names for variables, for example "value", "equals", "data", ... are not valid names for any case.
3. Use meaningful names for variables. Variable name must define the exact explanation of its content.
4. Don't start variables with o_, obj_, m_ etc. A variable does not need tags which states it is a variable.
5. Obey company naming standards and write variable names consistently in application: e.g. txtUserName, lblUserName, cmbSchoolType, ... Otherwise readability will reduce and find/replace tools will be unusable.
6. Obey programming language standards and don't use lowercase/uppercase characters inconsistently: e.g. userName, UserName, USER_NAME, m_userName, username, ...
   1.  
      • use Camel Case (aka Upper Camel Case) for classes: VelocityResponseWriter
      • use Lower Case for packages: com.company.project.ui
      • use Mixed Case (aka Lower Camel Case) for variables: studentName
      • use Upper Case for constants : MAX_PARAMETER_COUNT = 100
      • use Camel Case for enum class names and Upper Case for enum values.
      • don't use '_' anywhere except constants and enum values (which are constants).
   • For example for Java, 
7. Don't reuse same variable name in the same class in different contexts: e.g. in method, constructor, class. So you can provide more simplicity for understandability and maintainability.
8. Don't use same variable for different purposes in a method, conditional etc. Create a new and different named variable instead. This is also important for maintainability and readability.
9. Don't use non-ASCII chars in variable names. Those may run on your platform but may not on others.
10. Don't use too long variable names (e.g. 50 chars). Long names will bring ugly and hard-to-read code, also may not run on some compilers because of character limit.
11. Decide and use one natural language for naming, e.g. using mixed English and German names will be inconsistent and unreadable.
12. Use meaningful names for methods. The name must specify the exact action of the method and for most cases must start with a verb. (e.g. createPasswordHash)
13. Obey company naming standards and write method names consistently in application: e.g. getTxtUserName(), getLblUserName(), isStudentApproved(), ... Otherwise readability will reduce and find/replace tools will be unusable.
14. Obey programming language standards and don't use lowercase/uppercase characters inconsistently: e.g. getUserName, GetUserName, getusername, ...
    • For example for Java, 
      • use  Mixed Case  for method names: getStudentSchoolType 
      • use  Mixed Case  for method parameters: setSchoolName(String schoolName)
15. Use meaningful names for method parameters, so it can documentate itself in case of no documentation.

https://dzone.com/articles/best-practices-variable-and

Junit best practice

• Don’t aim at unit testing each method in the SUT. Unit test only the publicly available API.
• When writing unit tests, mimic the behavior of the SUT’s clients.
• Don’t test private methods. Either unit test them indirectly, using the public API, or extract them into separate classes and test those classes instead.
• Don’t hesitate to unit test internal classes as long as you follow the guidelines above
• Test data should  kept and read from a file instead of string variable

https://enterprisecraftsmanship.com/2017/10/23/unit-testing-private-methods/

• JUnit antipatterns
• unit-testing-anti-patterns-catalogue

Unit Test Naving Conventions: 

• 7-popular-unit-test-naming

Basic Git commands




Create a new local branch from remote branch: 

git checkout <new-branch>.

git checkout -b <new-branch> <existing-branch>


$ git branch -a* feature/development_0.0.0  master  remotes/origin/HEAD -> origin/master  remotes/origin/develop
  remotes/origin/feature/development_1.0.0
  remotes/origin/masterExample : I will checkout the remote branch origin/feature/development_1.0.0  to the new local branch "feature/development_1.0.0"  git checkout -b "feature/development_1.0.0" "origin/feature/development_1.0.0"

Delete a local branch :

Before deleting the branch make sure the branch is not currently checked out. 

git branch -d <lOCAL-branch>

Show all the local and remote branch :

git branch -a

Add all the changes: 

git add .

Git commit with message :

git commit -m "my commit message"

# Show All tags : $ git tag# Git Reset

$git reset --soft "49055cea321e4468e42853e47a4a6fc3bd21134a"

Load Test Using JMeter

What is JMeter?

JMeter is an software that can be used to execute performance testing, load testing and functional testing of your web applications. JMeter can also simulate a heavy load on a server by creating tons of virtual concurrent users to web server.

Please find more details here


In this test I will show you how we can run a simple API load test using Jmeter:

API on which load test will be run:

http://samples.openweathermap.org/data/2.5/weather?q=London,uk&appid=b6907d289e10d714a6e88b30761fae22

You can find details info here:

https://www.openweathermap.org/current

1. Open Apache Jmeter

2. Add a new thread group

Configure thread group using following settings:

Number of Thread (user) L:10

Ramp-Up Period: 5

Loop Count = Foreever

Scheduler = true

Duration : 30 second

3. add a new sampler

Configure HTTP Request using following settings:

Server: samples.openweathermap.org

Path : /data/2.5/weather?q=London,uk&appid=b6907d289e10d714a6e88b30761fae22

4. Add a New Config element 

You can add different heads information using HTTP header manager. (not required for this load test)

5. Add a new Listener 

6. Execute the test and see the result 

Details about different configuration option :

Number of Threads: Number of users to simulate

Ramp-up Period: To initialize the users on to server

Loop Count: Denotes the number of times the user to perform a particular test

Delay Thread creation until needed: Waits until the completion of the time mentioned to create threads

Scheduler :To enable or disable the scheduler

Start Time: Available only after enable of scheduler, used to mention at what point of time the execution need to be started

End Time :Available only after enable of scheduler, used to mention at what point of time the execution need to be stopped

Duration :Available only after enable of scheduler, used to mention how long the execution is to be happened.
Note: If duration time is mentioned, then the end time will be ignored

Startup delay :Available only after enable of scheduler, used to choose the startup delay

https://www.quora.com/What-is-the-meaning-of-ramp-up-period-and-loop-count-in-JMeter