• It’s a good practice.
• You are following the scientific method.
• If you change several things before any testing, then the testing of each will be more difficult, and perhaps not reliable, since preconditions will be more difficult to prepare and the different changes can interact with each other in manners you didn’t foresee.
• The time you feel you are “wasting” now, you will regain later in the intregration, testing and maintaining stages.
• Way to go.

Making lots of little changes and testing each one is not a bad thing. It allows you to see the effect of each change, and then when one change causes a problem, it’s much easier to know which change caused issues – the most recent one!

If you have a task list with 10 items, and you do all of them at once and then test the page and then notice that the page looks wrong, it might be harder to know which change broke the page.

Of course, it’s possible to take this approach to the extreme. Finding balance is the key, and that comes with gaining a better understanding of what you’re changing and how the changes might affect each other.

Your question has two parts:

1. should I perform them all once and then test them together ?

   I assume you are using a VCS.
   And to track, what tasks were done it makes sense to distribute the list of tasks to a list of commits: one task, one commit.

   That makes it easy to manage different versions of the current code base; you could revert to a previous state, cherry-pick the changes you want to enter the main trunk, etc.

   The answer is cleary:

   No, make changes only one by one – one task one commit.

2. but I got a bad habit of making small small changes and then test them again and again in web browser, is this a good practice ?

   It is a good practice to test code/UI whatever, but it is nonsense to do it over and over again in the browser. There are tools, to do that automatically for you (Selenium, PhantomJS/Casper, ZombieJS)

   The answer for this case is:

   Yes, it is good practice to test software more than once, but use automation

For any habit a developer has, there are 2 main questions:

1. How does it influence the quality of the code you make?
2. How does it influence your productivity?

If the answer to both is “It makes it better”, screw habit, teach it to others!
If the answer to one is “Better” and the other “Worse” – it’s a style and you have to be conscious about it. It’s not always applicable, and you may need to make an effort to suppress it every now and then.
If the answer to both is “Negative” – you’ve got a serious problem.

Of course for the first 2 cases you should also think about “Can the positive effect be somehow automated or institutionalized?”. Maybe it’s better to write a test than try out different browsers every time? (Note, I know that it’s not that easy to test proper layout in web development, I’m not saying this is always possible or worth the time).

In this particular case, it seems to me that the quality is increased, productivity may be decreased. For small changes it’s likely kinda bad (especially if the changes are interrelated), for larger – it’s kinda good. As long as you test the end result as well (avoid the “each module was tested and works, so the entire thing works as well, no need to test it!”).

Hence – unless 90% of your work day is doing really small changes – it’s a perfectly fine habit to have. If your work day is like that, then maybe you might want to review your work style (or work place).

This depends on the domain. For laying out a web page it will work fine and you can get immediate feedback (you can even do it in the browser directly!). Similarly it would work well for anything that doesn’t require a long time to initialize. This is preferred since it keeps your mental workload low and reduces the possibility of mistakes.

However, for really big projects where you have to compile the code and the time taken is non-trivial (several minutes), this can result in a lot of down time so you often have to resort to:

• “parallelizing” your work flow (e.g. work on multiple builds simultaneously), or
• do as many things as possible in one go, or
• create a small independent part to work on and integrate into the larger project later.

(There are probably other ways too.)

As others have stated, this is definitely not a bad habit. I generally prefer to make only a few modifications at once. The only exception is if I have a large list of changes that don’t all affect one another (e.g. changes to minor styles or copy, changes on different pages, etc). If you’re modifying layouts, stick to making changes one at a time so you can verify everything is 100% in all supported browsers before moving onto the next issue.