Q:

Why is it often said that the test cases need to be made before we start coding? 

Why is it often said that the test cases need to be made before we start coding? 
What are its pros and what the cons if we don't listen to this advice? 
Moreover, does that advice refer to black box testing or White Box testing or both? 

A:

Writing tests before implementations is one of the core ideas behind Test Driven Development (TDD).  The procedure is:

write a failing test
change the code to make it pass, without breaking any other test
refactor the code, verify that all tests still pass

This procedure is the same whether you implement a feature or fix a bug; it is often referred to as "Red-Green-Refactor" (red = test fails, green = test passes).  The advantages of this method are numerous:

the test clearly defines what constitutes "done"
the test documents how you intend the code to be used
if you do it right, you build a complete test suite with 100% coverage as a by-product of your development process, which means you always have reliable regression tests at hand no matter what you do
coding to meet a test case (and nothing else) helps keep you focused on one task and prevents feature creep
the red-green-refactor cycle makes for a nice, clean and tracable commit history and fits a feature branch repository approach well (each feature branch starts with a commit that adds a failing test, then one or more commits until "green" is reached, and then one or more refactoring commits). 
you produce working versions at regular intervals - ideally, each red-green-refactor cycle ends with a potentially shippable product, but at the very least, it should build without failures and pass all the tests. 

Now for the downsides:

Not all code lends itself to automated testing.  This can be because it's a legacy codebase written without automated tests in mind; it can be because the problem domain is such that certain things cannot be mocked; or maybe you rely on external data sources that are not under your control and would be too complicated to mock; etc. 
Sometimes, correctness, maintainability and stability are not high enough on the priority list.  This sounds bad, but it doesn't have to be: if you're writing a one-use script to batch convert a bunch of documents, writing tests at all is silly - you just run it on a few test documents, eyeball the result, and that's that.  Automated testing wouldn't add any value here. 
Writing the test before writing the code implies that you already know exactly what you want done.  Quite often, though, you don't, and a significant amount of explorative programming is required to get a feeling for the particular problem domain; and more often than not, the results of such explorative coding are then bashed into shape to become the real product.  Automated tests are just as valuable for such products, but it doesn't make much sense adding them before you know what you're going to make.  In this case, it's better to take the prototype at the end of the explorative phase, add tests to cover everything you have so far, and switch to red-green-refactor from there. 
Test-before-implementation isn't everyone's cup of tea; writing the implementation first feels more natural, and some people have an easier time getting into a flow that way

A:

Why is it often said that the test cases need to be made before we start coding? 

It's a basic principle of test-driven development, but not a general "best practice".  Not everyone wants or needs to do TDD, even though its proponents often claim that everyone would benefit from it. 

What are its pros and what the cons if we don't listen to this advice? 

The advantage is that it forces you to think about your code from a perspective of testing before you write it, which has two main advantages: you're less likely to forget about special cases and boundary conditions, and your code has to be testable and thus modular.  Another important benefit: at any time you know that your code is working as you thought it should. 
The disadvantage is that it may encourage thinking about low-level details and overlook important design issues (but the same can happen if you just start coding).  Also, the most easily testable design is not necessarily the best (but probably much better than one grown out of ad hoc coding). 
Of course there's the question whether TDD saves more time than writing all those unit tests costs.  Its proponents certainly claim so. 

Moreover, does that advice refer to black box testing or White Box testing or both? 

Usually, TDD deals exclusively with unit tests, which are white box tests.  Integration tests have to be done additionally. 

A:

When I am writing test first, it isn't much a matter of verifying correct functioning of my code, not really a matter of black box or white box or whatever related to quality assurance, and here is why...
Over the years I practiced and polished a skill to convince management that I need good testers 1, 2, 3 and this suffices to ensure that my code will work as intended without me having to think much about it. 
Main reason why I prefer test first is it helps me understand how to design my code so that it's convenient to use.  I am not good at imagining in my head how my module will be used by other modules so I can do it overly complicated and that will bite me later and possibly even require redesign. 
This is a problem no matter whether I am coding a module for myself or for someone else, it is equally painful using inconvenient interface myself as well as having to explain its usage to other programmers. 

"Test-first" approach saves me from that pain; it doesn't require imagination to immediately see how my module will be used if designed this or that way and makes it easy to choose the more convenient one. 
When coding module for someone else, it also saves me from the need to painfully explain how to use it. 

Look, code in this test shows how you should use that module and if you run it, you'll also see what results you should expect.  Using any other way than shown in this test would be a mistake.  Now go away and let me do something interesting.