Featured

Tips for clean coding in java

I am required to read quite a bit of code written by other people, and over the years I’ve found that there are some problems that tend to recur again and again. The idea with this blog entry is to write up some tips , in the hope that it can help people out there who struggle to write clean code.

These are the tips for clean coding or good coding.

 

Keep classes small

So far you’ve created a few classes. After generating getter/setter pairs for even the small number (by the standards of a real-world Java class) of attributes, the Person class has 150 lines of code. At that size, Person is a small class. It’s not uncommon (and it’s unfortunate) to see classes with 50 or 100 methods and a thousand lines or more of source. Some classes might be that large out of necessity, but most likely they need to be refactored. Refactoring is changing the design of existing code without changing its results. I recommend that you follow this best practice.

In general, a class represents a conceptual entity in your application, and a class’s size should reflect only the functionality to do whatever that entity needs to do. Keep your classes tightly focused to do a small number of things and do them well.

Keep only the methods that you need. If you need several helper methods that do essentially the same thing but take different parameters (such as the printAudit() method), that’s a fine choice. But be sure to limit the list of methods to what you need, and no more.

Name methods carefully

A good coding pattern when it comes to method names is the intention-revealing method-names pattern. This pattern is easiest to understand with a simple example. Which of the following method names is easier to decipher at a glance?

  • a()
  • computeInterest()

The answer should be obvious, yet for some reason, programmers have a tendency to give methods (and variables, for that matter) small, abbreviated names. Certainly, a ridiculously long name can be inconvenient, but a name that conveys what a method does needn’t be ridiculously long. Six months after you write a bunch of code, you might not remember what you meant to do with a method called compInt(), but it’s obvious that a method called computeInterest(), well, probably computes interest.

 

Omit needless code!

It’s quite common to find code that’s commented out, but still hanging around. This is mainly bad because it bloats the code unnecessarily. People seem to do this because they want to have the possibility to bring the code back, either because they are writing an alternative they are not sure about, because they don’t dare to delete it. However, in nearly all cases there is no real reason to keep such code around. You should be using version control, and that means you could always find any deleted code again.

Also, since this code is no longer compiled or executed there is no real difference between commenting it out or deleting it. You’ve still made the change. The difference is that now it’s quite likely that this code will slowly move out of sync with the code around it, so that by the time you find you want it again it will no longer work. That actually makes the code dangerous, because it tempts you to include code without understanding what it does. (If you really understood it you could retype it quite quickly even if it was deleted.)

Of course, commenting out code while you are working on the code is fine. I do that a lot. However, I never check in code that is commented out, and whenever I find such code I delete it, without asking anyone or telling them. If they wanted the code they shouldn’t have commented it out. And it will be in the version history, anyway.

I chose this topic because i want to write code in a clean, efficient and faster way. I also chose this topic because since we will be studying it in the CS-343 class , why not learn ahead to get much more understanding on it.

Even though i knew some things about clean coding, i learned a lot. Some stuff i didn’t know where there. With these materials i have gain from other blogs or website added to my little knowledge of clean coding , i hope it will help me develop better coding in a clean, efficient and faster way.

 

I got the above information from this link ::: https://www.ibm.com/developerworks/library/j-perry-writing-good-java-code/index.html 

And

http://www.garshol.priv.no/blog/105.html

Advertisements

Test Automation

The reason of this area of research was to know why test Automation is better than other kind of testing and also get to know more about it.

First, Automation, is the use of tools and strategies that reduce human involvement or interaction in unskilled, repetitive or redundant tasks.

The automated test lifecycle methodology 

1.outline the potential benefits and test tool proposal

2.test tool evaluation and selection

3.Steps necessary to outline automated testing to the project

4.Identifies the test procedure standards, defines the tests, defines development standard

5.Test plans are executed

6.This is done throughout the lifecycle

 

why automation?

Verification – developed software matches the requirements

Validation – it is what the organisation wanted

Defects and failures – incorrectly setup environments  or wrong version of software being deployed – human error –  bug or malfunction – system malfunctioning or failing

Compatible – so that new software deployed wont mess up any existing apps

According to smartbear, Every software development group tests its products, yet delivered software always has defects. Test engineers strive to catch them before the product is released but they always creep in and they often reappear, even with the best manual testing processes. Test Automation software is the best way to increase the effectiveness, efficiency and coverage of your software testing.

Manual software testing is performed by a human sitting in front of a computer carefully going through application screens, trying various usage and input combinations, comparing the results to the expected behavior and recording their observations. Manual tests are repeated often during development cycles for source code changes and other situations like multiple operating environments and hardware configurations. An automated testing tool is able to playback pre-recorded and predefined actions, compare the results to the expected behavior and report the success or failure of these manual tests to a test engineer. Once automated tests are created they can easily be repeated and they can be extended to perform tasks impossible with manual testing. Because of this, savvy managers have found that automated software testing is an essential component of successful development projects.

The advantages of automation

Reliable: carries out the same operations – eliminating human error
Reusable: can reuse tests on different versions of an application
Better Quality Software: can run more tests in less time with fewer resources – good coverage
Fast: run tests significantly faster than human users.
Cost Reduction: number of resources for tests are reduced.

Replaces: manually mundane and labor intensive tasks

 

 

In conclusion, i learned that testing in automation tests for ever-shrinking schedules and minimal resources, i got the understanding of the automated software testing lifecycle and also the usefulness of it. I also got to know, it has a zero risk of missing out a pre-decided test. Once the test becomes a part of continuous integration, it will run without someone having to remember to run it.

 

References :

http://www.my-project-management-expert.com/software-application-testing.html

https://smartbear.com/learn/automated-testing/what-is-automated-testing/

https://smartbear.com/learn/automated-testing/

black box and white box testing #443

I picked this article just to get more understanding on black box and white box testing. Also wanted to know the differences between them.

White box testing is testing where we use the info available from the code of the component to generate tests.

This info is usually used to achieve coverage in one way or another – e.g.

  • Code coverage
  • Path coverage
  • Decision coverage

Debugging will always be white-box testing

 

White box testing types

 

3 Main White Box Testing Techniques:

  1. Statement Coverage
  2. Branch Coverage
  3. Path Coverage

 Statement coverage:

In a programming language, a statement is nothing but the line of code or instruction for the computer to understand and act accordingly. A statement becomes an executable statement when it gets compiled and converted into the object code and performs the action when the program is in a running mode.

Hence “Statement Coverage”, as the name itself suggests, it is the method of validating whether each and every line of the code is executed at least once.

Branch Coverage:

“Branch” in a programming language is like the “IF statements”. An IF statement has two branches: True and False.

So in Branch coverage (also called Decision coverage), we validate whether each branch is executed at least once.

In case of an “IF statement”, there will be two test conditions:

  • One to validate the true branch and,
  • Other to validate the false branch.

Hence, in theory, Branch Coverage is a testing method which is when executed ensures that each and every branch from each decision point is executed.

 Path Coverage

Path coverage tests all the paths of the program. This is a comprehensive technique which ensures that all the paths of the program are traversed at least once. Path Coverage is even more powerful than Branch coverage. This technique is useful for testing the complex programs.

Black box testing is also called functional testing. The main ideas are simple:

1.Define initial component state, input and expected output for the test.

2.Set the component in the required state.

3.Give the defined input

4.Observe the output and compare to the expected output.

  • black-box is based on requirements and functionality, not code
  • tester may have actually seen the code before (“gray box”)but doesn’t look at it while constructing the tests
  • often done from the end user or OO client’s perspective
  • emphasis on parameters, inputs/outputs (and their validity)

Types of Black Box Testing

  • requirements based
  • positive/negative – checks both good/bad results
  • boundary value analysis
  • decision tables
  • equivalence partitioning – group related inputs/outputs
  • state-based – based on object state diagrams
  • compatibility testing
  • user documentation testing
  • domain testing

 

Black Box vs. White Box testing

We can contrast the two methods as follows:

  • White Box testing

–Understanding the implemented code.

–Checking the implementation

–Debugging

  • Black Box testing

–Understanding the algorithm used.

–Checking the solution – functional testing

This article will really help me in the future in terms of testing of coding. I got better understanding and also got the differences between the two. Even dough i had an idea of it, this has really help me.

 

Links: http://www.cs.unh.edu/~it666/reading_list/Defense/blackbox_vs_whitebox_testing.pdf

https://www.guru99.com/back-box-vs-white-box-testing.html

https://www.softwaretestinghelp.com/white-box-testing-techniques-with-example/

Causes of software errors #443

I picked this article because i wanted to better understand the term error(s) under testing. What actually got me to do this research was the causes of errors in software development.

first let know the terms of software error, fault and failures. Software error is made by programmer, like syntax error or logic error. Software fault is a part of the software which may not execute. Software Failures, this is due how the software is executed.

Some of the causes that i searched throw were:

Faulty Requirements Definition

  • Usually considered the root cause of software errors
  • Incorrect requirement definitions
  • Simply stated, ‘wrong’ definitions (formulas, etc.)
  • Incomplete definitions
  • Unclear or implied requirements
  • Missing requirements
  • Just flat-out ‘missing.’ (e.g. Program Element Code)
  • Inclusion of unneeded requirements
  • (Many projects have gone amuck for including far too many requirements that will never be used.

Impacts budgets, complexity, development time

 

Client-developer communication failures

  • Misunderstanding of instructions in requirements documentation (written / graphical instructions)
  • Misunderstanding of written changes during development.
  • Misunderstanding of oral changes during development.
  • Lack of attention
  • to client messages by developers dealing with requirement changes and
  • to client responses by clients to developer questions
  • Very often, these very talented individuals come from different planets, it seems.
  • Clients represent the users; developers represent a different mindset entirely sometimes!

 

Coding errors

  • Too many to try to list.
    • Syntax errors (grammatical errors)
    • Logic errors (program runs; results wrong)
    • Run-time errors (crash during execution)
    • Know the differences. Be also able to supply an example.  Examples do not ‘define’ something, but they may be used to ‘support’ or ‘supplement’ a definition.

Logical design errors

  • Omission of required software system states
  • If rank is >= O1 and RPI is numeric, then….easy to miss an action based on the software system state.
  • Omission of definitions / procedures concerning reactions to illegal operation of the software system.
  • Including not only code to detect an illegal operation but failure to design the computer software reaction to this: Gracefully terminate, sound   alarm, etc
  • an error is a human activity resulting in software containing a fault
  • a fault is the manifestation of an error
  • a fault may result in a failure
  • Failure is a relative notion: e.g. a failure w.r.t. the specification document
  • Verification: evaluate a product to see whether it satisfies the conditions specified at the start

 

I got to learn more about errors, what happens when error occurs and how identify them.  These articles that i have searched and learned will help me identify bug, or even error very quick. And also in an organized fashion.

links: https://www.testingexcellence.com/error-fault-failure-software-testing/

https://www.tutorialspoint.com/software_testing_dictionary/error.htm

https://www.softwaretestingmaterial.coI m/difference-between-defect-bug-error-and-failure/

 

Static vs. Dynamic Testing (week-6)

On week 6, i did some research on static and Dynamic testing. The main reason for picking this topic is to know ahead before we start talking about it in class. In that way i am able to follow and ask question that i may want to ask the prof.

I learned a whole lot, first this is what learned on static testing. It does not execute code. It manually checks work documents to find errors in early stage.

Some benefits of static testing techniques.

  1. lifetime cost reduction
  2. reduced fault levels
  3. improved customer relations
  4. development productivity improvement
  5. And also reduced development timescales

Some of the information i got from dynamic testing. From my understanding, it is a term used to describe the testing of the dynamic behavior of code.  Not like the static testing which does not execute code, dynamic testing does, it involves working with the software, giving input values and checking if the output is as expected.

Dynamic testing is the validation portion of verification and validation. some of the validation activities are unit tests, integration tests, system tests and acceptance tests

some techniques on dynamic testing

 

graphical representation of dynamic testing techniques

Static Testing Vs Dynamic Testing

from one of the links(blogs) below gives the techniques of dynamic testing

  • Unit Testing:Under Unit Testing ,  individual units or modules is  tested by the developers. It  involves testing of source code by developers.
  • Integration Testing: Individual modules are grouped together and tested by the developers. The purpose is to determine that modules are working as expected once they are integrated.
  • System Testing: System Testing is performed on the whole system by checking whether the system or application meets the requirement specification document.

Through the research got to know static and dynamic testing complement to one another and each type has a unique approach to detecting bugs.

also got to know white box testing where developers verity or check code to find fault is derived from static testing system.

one also big different about static and dynamic is that, static testing is about prevention whereas dynamic testing is about cure.

 

These articles or blogs really helped my understanding of these two testing, static testing and dynamic testing.

references : https://www.guru99.com/static-dynamic-testing.html

https://www.softwaretestingclass.com/difference-between-static-testing-and-dynamic-testing/

https://www.360logica.com/blog/difference-between-static-testing-and-dynamic-testing/

Behavioral vs Structural Testing (week-5)

I picked this topic because i was a little bit confused with the test-driven development and the behavior-driven development. And also wanted to know the differences between them.

Since all what we do is testing, let me give a little insight on unit testing. Unit testing by Wikipedia, is a software testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine whether they are fit for use.

Testing encourages developers to modify the source code without immediate concerns about how such changes might affect the functioning of other units or the program as a whole.

So terms i got to know, Unit test which is a single piece of code tested. Integration test which is a multiple pieces tested together. An example of integration test will be a database access code against a test database. And also Acceptance test which automatic test the entire application.

Test-Driven Development also known as TDD

TDD is a process for when you write and run your tests. TDD reduces the likelihood of having bugs in your tests, which can otherwise be difficult to track down. TDD is broken up into five different states:

  1. first the developer writes some tests.
  2. the developer then runs those tests and they fail because none of those features are actually implemented.
  3. Next the developer actually implements those tests in code.
  4. If the developer writes their code well, then the in next stage they will see that their tests pass.
  5. The developer can then refactor their code, add comments and clean it up, as they wish because the developer knows that if the new code breaks something, then the tests will be an alert by failing.

The normal approach that TDD dictates is to use the function and then assert that the result satisfies a certain value.

 

Now lets talk about Behavior-Driven Development

Behavior-Driven Development

Also known as BDD. This is a set of best practices for writing great tests. BDD is actually meant to eliminate issues that TDD might cause.

an example is given below:

suite('Counter', function() {
  test('tick increases count to 1', function() {
    var counter = new Counter();
 
    counter.tick();
 
    assert.equal(counter.count, 1);
  });
})

 

From what i leaned from this blog, i noticed Unit testing gives you the what, Test-Driven Development gives you the when and Behavior Driven-Development gives you the how. I also got much understanding of the three very well. I think this is going to really help me with my project or class work on testing.

 

Link https://codeutopia.net/blog/2015/03/01/unit-testing-tdd-and-bdd/

Junit (week-4)

JUnit is a unit testing framework for Java programming language. JUnit improve software design, makes software easier to understand, reduce debugging time, catch integration errors and in short to produce better code.

Choosing this topic has made me understand JUnit very clear. I have come to know the types of JUnit. Also come to know the use of testing driven development. As in the Test Driven Development, it is a software development process in which tests are written based on the requirements before any coding begins.

On the Test Driven Development(TDD), i also got to know its life-cycle. which are

  1. write the test
  2. run the test
  3. write just enough implementation code to make the test pas
  4. run all tests
  5. refactor
  6. repeat

Also go to know TDD is not about testing but development,specifically improving the quality and design of code.

Also learned what Code Coverage, which is the measuring how much of your code is executed during your unit tests.

Some best practice for measuring code coverage are

1.  use a code coverge tool like Sonar or JaCoCo. These tools help because they can point out areas of the code that are untested. Also Code Coverage does not guarantee the tests are perfect.

2.  Ensure that there are test cases that over all the branches of the code, i.e. if/else statement.

 

Another tip i got was, instead of using the print statement, rather use the assertions.

for instance:

 public class StringUtil {
    public String concat(String a,String b) {
        return a + b;
    }
    }
These are the two testing method
1)
@Test
public void testStringUtil_Bad() {
String result = stringUtil.concat(“Hello “, “World”);
System.out.println(“Result is “+result);
}
2)
@Test
public void testStringUtil_Good() {
String result = stringUtil.concat(“Hello “, “World”);
assertEquals(“Hello World”, result);
}
The first test is the print method and the second one is the assertion method.
the reason why you have to use the assertion is because it automatically indicate test results. but the print statement does not.

I really enjoy reading this article containing some interesting topics, which in the future will help me a lot. I got the understanding of some part of Junit testing in java and tips that i will using. The JaCoCo application for measuring how much code is executed during testing was a little confusing. but with time will understand it better.

 

Link : https://stormpath.com/blog/7-tips-writing-unit-tests-java

 

System Testing

System Testing 

 How to do System Testing?

 

i learned some ways to take when you are about to do system testing. I notics, in software system testing , testing has to follow some specific steps. which are below,

Step 1) First & important step is preparation of System Test Plan

 Step 2) Second step is to creation Test Cases:

 Step 3) Creation of test data which used for System testing.

Step 4) Automated test case execution.

Step 5) Execution of normal test case & update test case if using any test management tool (if any).

Step 6) Bug Reporting, Bug verification & Regression testing.

Step 7) Repeat testing life cycle (if required).

 

To get more about this topic, visit or click on this link System Testing .