Technical checklist: How to start coding new project

Even a fresh graduate out of university or a college student can do programming. They can create websites, mobile applications, and much more stuff. But inexperience person with quick start of a project without considering important aspects can result in a lot of problems. In fact, seasoned programmers who don’t consider important factors before starting project end up with similar problems. Remember, experience is although listed in number of years, but maturity, quality and efficiency  don’t come only by understanding and fixing problems but also not doing same mistakes again and again. Maturity come by learning from own and others mistakes.

So whether you are a seasoned programmer or a new programmer, here is a check list having some important things to consider before starting your next project. Here I am more focusing on programming related stuff not project management side.

Understand the big pictures:

Even though we are not focusing on project management size but at any level understanding the big picture is very much important. Even if your work is a small part of something big, still you should at-least understand how your work is going to interact with and will be integrated with rest of system. This will let  you avoid many small mistakes which can later appear as big problems. Also based on big picture you can better decide about technology and approach for your work.

Some documents are helpful:

Yeah I know lot of documentation sometime overshadow actual development process. I am not asking for that. But you should at-least have some sort of  diagrams which clearly state important flows, rules and relations. If that is not possible then should have a bullet point document so that your client can understand what you are going to do before seeing something actually coded and working in-front of him and believe me it will be really helpful for you to develop something that is decided and listed instead of developing while thinking about missing pieces.

Have  a DB diagram:

If you are using a database in your project then you should at-least have an initial DB diagram ahead of coding business logic to keep you on track. Try to create a DB diagram even if you have decided to not making any other diagram.

Write and run Test Cases:

I understand that most of programmers don’t have time for writing test cases. It consume time to write more code for testing your code. But there are already such testing frameworks which can make your work a lot easier. It will still take time to write tests but it will really rescue you in case of any major change requested by client or due to some mistake . In the middle of project, developers hesitate to change existing functionality because that can break some parts of system that no body will know before shipping code that can break while in production.

But sometime it is crucial to do such major changes so here automated testing tools can rescue you. These test cases let programmer know that where change is effecting. So that programmer can fix those places before shipping and rerun all test cases. It provides much more confidence to developer over his code.  It is up to you  that which type of testing you want to use and which framework you want to use for that.

In fact, in my last project client 2 times asked for such major changes and we already had test cases written, so after doing changes I just ran test cases and it showed me the test cases failures. So I fixed those parts accordingly. So after doing all changes and fixing everything I again ran test cases and at the end I was confident that now there wasn’t any remaining broken thing due to that major change.

If still not convinced that Automated Testing can make your life better, then see a this question answer format article: Why to write test cases using Automated Testing tools?

Use Latest Stable version:

Always use latest stable version of a framework or library if possible. Because the product or project you are developing right now will be in production after some time and then it will remain in production for much more time. So use latest stable version available so that you or product owner don’t need to upgrade libraries or frameworks again and again and can utilize latest features from day one.

Version Control is always important:

Version control tools are not only useful for keeping versions and history but it can be useful as a tool for auto merging different team-mates’ work too. Other than that, it is very helpful for having an on-line backup other than on your system so one can access it from anywhere as well as it is safer to not rely on single system.

Use Dependency Injection:

If your framework or library provide a way of dependency injection then use that or get dependencies available for your class in class’ constructor instead of separately instantiating objects in different methods of a class. Because this way you will not only know your class dependencies easily but you can also replace them easily if you want.

Use Interfaces:

Try to always use interfaces instead of concrete classes for instantiating objects. Interfaces make your code loosely coupled and let you swap parts of system much more easily.

Use thinner Controller:

If you are using MVC pattern then your controller must only have, required things and should be thinner. And reusable stuff should never be in controller but in library, helper or model etc.

Respect SOLID:

As per wikipedia, SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) is a mnemonic acronym introduced by Michael Feathers for the “first five principles” named by Robert C. Martin in the early 2000s that stands for five basic principles of object-oriented programming and design. Here you can find more information about SOLID.

However what I want to say is that SOLID will make your programming and work better. And your code will be much more flexible and clean.

So these are few things which are in my checklist, let me know if there is something else that you think that it should be added in this list. I will try to later attach detailed articles to most of these points which need more clarification or detail.


API Testing: Selecting Testing Framework ( PHP Unit vs Codeception vs Behat )

This entry is part 2 of 3 in the series API Testing

In previous article of this series, we discussed that why you should use automated testing, specially if you are writing APIs.  So now it is time for selecting right tools for doing our API testing.

Available Testing Framework:

As there are application development frameworks to make your life easy, there are also many different testing frameworks which can be used for automated testing. Now point is that what framework you should use? It all depends. All have their pros. Important is what you want to achieve, how much time do you have.  When I was first time writing tests to test APIs, I took  4 days from client to find tool and write test cases so that, it can save me from manually testing all API endpoints and test cases before committing my code and leaving office. Yes, if you will not have automated tool then you will need to do lot of manual testing every day.

Anyways, my project was in Laravel 4 and by doing some search on Google, I came with three PHP based testing frameworks.

  1.  PHP Unit: Because it is basic and starting from basic is easy.
  2. CodeCeption: BDD-style PHP testing framework, it was more than basic, but can be used for different sort of testing.
  3. Behat: It is a tool for Behaviour driven development. It means that test are ;written in human readable sentences that describes your application’s features.

Here is more detail about them with Pros and Cons:

PHP Unit:

PHP Unit is basic testing tool and first thing that can come to mind or (at time of writing) first record  come in Google search result if you search “PHP testing”. And PHP Unit older than all the above mentioned, its initial released was in 2004, so that means it is mature enough.

Pros of PHP Unit:

  1. It is mature and very popular and that’s why good documentation, lot of tutorials and lot of threads on Q&A boards and on forums.
  2. It is basic and basic is often simpler to start, when you are doing some thing first time or new in something.
  3. PHP Unit is probably one of the best known tool for Unit Testing, as clear from its name too.

Cons of PHP Unit:

  1. PHP Unit can be the best tool for Unit testing but API testing is different, so it is probably not better to use it for API testing or acceptance testing because, these are higher level different than Unit testing.
  2. PHP Unit is very limited. It is easy to understand the basic but if you need more than that and want to higher level stuff then either you will need to integrate different tools with PHP Unit or will need to write lot of code to write higher level tests like API testing.



Codeception is known as BDD-style testing framework. If you go to you will be able to see lot of different examples  for different type of testing. It is something that can fit to one’s needs in very different ways.

Pros of Codeception:

  1. It is more than basic with lot of features available for different type of testing, no matter if it is low level like Unit testing or higher level like API testing or if it is BDD.
  2. Even with lot of feature it is not that much difficult, it is easier that can be seen from homepage of Codeception.
  3. It have separate modules for many PHP frameworks like Symfony2, Laravel4, Yii, Phalcon, Zend Framework. It don’t mean that it only support these frameworks but if you are using these frameworks and use its these modules, it will provide better features like errors will be more clear, and debugging will be easier however that can result in more memory usage in some cases.
  4. It provides support for different other testing frameworks if you want to use them with it.
  5. Its Test Cases are written in PHP so programmer don’t need to know a different language for that.

Cons of Codeception:

  1. Codeception is no doubt an awesome tool but it probably don’t have as much documentation and resources compared to PHP Unit. However as it is powered by PHP Unit so one can go to that level to do something at low level too.
  2. Codeception is no doubt easier but not as much simpler and easier to configure and start as PHP Unit can be.
  3. Codeception is feature rich but it is still BDD-style tool not actually aimed at BDD and its test cases are written in PHP, so if you have a QA team who can’t write PHP then they can’t write different feature or scenarios of the system without touching PHP or programmer will need to write all those test cases.



Behat is a BDD tool. And this is the purpose fo which mainly Behat is used.

Pros of Behat:

  1.  As Behat is BDD framework so it’s language for writing test cases is very human friendly and person with no programming experience can write features easily.
  2. Like Codeception, Behat is feature rich tool.
  3. Behat test cases and cleaner and maintenance of tests in Behat is easier because a layer on which test case scenarios are being written is different than where these scenarios definitions are written.

Cons of Behat:

  1. Behat is no-doubt awesome tool for BDD but for things like API testing it will probably need more tools to integrate with it.
  2. If you don’t have a separate QA team and one programmer is writing tests then writing test case scenarios and its definitions separately will be bit more complex .
  3. Programmer need to understand Behat’s human friendly syntax called Gherkin.
  4. Due to more layers involved, for programmer who haven’t used it before, it can take more time to write test cases and understanding this tool.


As told above I had 4 days to look into Testing frameworks and writing some test cases for API testing and framework I was using was Laravel 4, so what I started using was Codeception. It isn’t about winner or loser, it was about which testing framework is right for you based on your requirements and time you have to learn and configure it.

I picked Codeception over PHPUnit because spending a little bit more time on configuring and learning  Codeception, I was able to save much more time during writing test cases for API Testing. And I picked Codeception over Behat because Codeception seemed to have less steaper learning curve than Behat because Codeception’s test cases are written in PHP instead of Gherkin. And I didn’t have any requirement for Gherkin (human friendly syntax) as I was the only person who was writing Test Cases.

So this was my choice based on my requirements but feel free to choose different testing framework based on your set of requirements. In next part of this series “Testing API”, we will look into how to install and configure codeception and will look into its different files and directories.