Writing tests first is a completely different approach to writing software. Tests are not only a tool of proper code functionality verification (they all pass) but the force that define the design. While test coverage might be a useful metric it must not be the goal in itself - the goal of TDD is not to get to a good % of code coverage, but to think about testability of your code before writing it.

If you have troubles with writing tests first, I would highly recommend doing a session of pair-programming with someone who is experienced in TDD, so that you get a hands on experience of "the way to think" about the whole approach.

Another good thing to do is to watch some online video where software is being developed using TDD from the very first line of it. Good one that I once used to introduce myself to TDD was Let's Play TDD by James Shore. Take a look, it will illustrate how emergent design works, what questions should you ask yourself while writing tests and how new classes and methods are created, refactored and iterated upon.

Is there any way you can identify whether test you have written are enough?

I believe this is the wrong question to ask when you do TDD, you chose to do TDD and emergent design as the way to write software. Please do not get tricked into using TDD only to get a good test coverage. That's not. If any new functionality you need to add to your software always starts with test, it will always be there and your question will make no sense.

Is it good practice to writing test for very simple functionality which might be equivalent to 1+1 = 2 or is it just an overplay?

I prefer not to write tests on parameters null checks, if the method is not part of public API, but otherwise, why would you not confirm that method Add(a,b) returns a+b indeed?

Is it good to change functionality and accordingly test if requirement changes?

Again, when you change or add new functionality to your code, you start with a test, whether it's adding new test or changing existing one when requirements change.

Writing tests first is a completely different approach to writing software. Tests are not only a tool of proper code functionality verification (they all pass) but the force that defines the design. While test coverage might be a useful metric, it must not be the goal in itself - the goal of TDD is not to get to a good % of code coverage, but to think about testability of your code before writing it.

If you have troubles with writing tests first, I would highly recommend doing a session of pair-programming with someone who is experienced in TDD, so that you get a hands on experience of "the way to think" about the whole approach.

Another good thing to do is to watch online video where software is being developed using TDD from the very first line of it. Good one that I once used to introduce myself to TDD was Let's Play TDD by James Shore. Take a look, it will illustrate how emergent design works, what questions should you ask yourself while writing tests and how new classes and methods are created, refactored and iterated upon.

Is there any way you can identify whether test you have written are enough?

I believe this is the wrong question to ask. When you do TDD, you chose to do TDD and emergent design as the way to write software. If any new functionality you need to add always starts with a test, it will always be there.

Is it good practice to writing test for very simple functionality which might be equivalent to 1+1 = 2 or is it just an overplay?

Obviously it depends, use your judgement. I prefer not to write tests on parameters null checks, if the method is not part of public API, but otherwise, why would you not confirm that method Add(a,b) returns a+b indeed?

Is it good to change functionality and accordingly test if requirement changes?

Again, when you change or add new functionality to your code, you start with a test, whether it's adding new test or changing existing one when requirements change.

Writing tests first is a completely different approach to writing software. Tests are not only a tool of proper code functionality (they all pass) but the force that define the design.

If you have troubles with writing tests first, I would highly recommend doing a session of pair-programming with someone who is experienced in TDD, so that you get a hands on experience of "the way to think" about the whole approach.

Another good thing to do is to watch some online video where software is being developed using TDD from the very first line of it. Good one that I once used to introduce myself to TDD was Let's Play TDD by James Shore. Take a look, it will illustrate how emergent design works, what questions should you ask yourself while writing tests and how new classes and methods are created, refactored and iterated upon.

Is there any way you can identify whether test you have written are enough?

I believe this is the wrong question to ask when you do TDD, you chose to do TDD and emergent design as the way to write software. Please do not get tricked into using TDD only to get a good test coverage. That's not. If any new functionality you need to add to your software always starts with test, it will always be there and your question will make no sense.

Is it good practice to writing test for very simple functionality which might be equivalent to 1+1 = 2 or is it just an overplay?

I prefer not to write tests on parameters null checks, if the method is not part of public API, but otherwise, why would you not confirm that method Add(a,b) returns a+b indeed?

Is it good to change functionality and accordingly test if requirement changes?

Again, when you change or add new functionality to your code, you start with a test, whether it's adding new test or changing existing one when requirements change.

Writing tests first is a completely different approach to writing software. Tests are not only a tool of proper code functionality verification (they all pass) but the force that define the design. While test coverage might be a useful metric it must not be the goal in itself - the goal of TDD is not to get to a good % of code coverage, but to think about testability of your code before writing it.

If you have troubles with writing tests first, I would highly recommend doing a session of pair-programming with someone who is experienced in TDD, so that you get a hands on experience of "the way to think" about the whole approach.

Another good thing to do is to watch some online video where software is being developed using TDD from the very first line of it. Good one that I once used to introduce myself to TDD was Let's Play TDD by James Shore. Take a look, it will illustrate how emergent design works, what questions should you ask yourself while writing tests and how new classes and methods are created, refactored and iterated upon.

Is there any way you can identify whether test you have written are enough?

I believe this is the wrong question to ask when you do TDD, you chose to do TDD and emergent design as the way to write software. Please do not get tricked into using TDD only to get a good test coverage. That's not. If any new functionality you need to add to your software always starts with test, it will always be there and your question will make no sense.

Is it good practice to writing test for very simple functionality which might be equivalent to 1+1 = 2 or is it just an overplay?

I prefer not to write tests on parameters null checks, if the method is not part of public API, but otherwise, why would you not confirm that method Add(a,b) returns a+b indeed?

Is it good to change functionality and accordingly test if requirement changes?

Again, when you change or add new functionality to your code, you start with a test, whether it's adding new test or changing existing one when requirements change.