The baseline of Unit testing is that it tests every piece of code in isolation without dependencies.
Let's understand it with the example of making a breakfast, e.g.Omelet.
Here you check the quality and quantity of each ingredient to make a delicious Omelet.
How many eggs? Are they fresh?
What kind of milk? How much? Is it spoiled?
Is your bowl (for scrambling) clean?
And so on...
Here you are checking each ingredient separately without mixing them. You’re doing a unit testing in this sense. You’re testing your work and units that will comprise the product.
But note that you’re not testing the product.
Now, let's say you found eggs unhealthy. Here you know that those eggs are going to ruin your morning and hence you will replace them with fresh eggs. That's the main benefit of unit testing where you can identify the piece of code which will cause a problem in future.
When you taste the omelet, you are doing Integration testing. Integration testing checks that whether all the components work together as expected.
P.S: Those who are older than five and want to dig more about Unit testing, can read this blog: simform.com/unit-testing-tdd
You think that your sister's china doll, that you hate so much, breaks when you drop it on the floor?
How would you find out if that is really case?
You would probably:
Get the doll from your sister's room
Drop it on the floor
Compare what you expected (the doll breaks) to what has actually happened (the doll is ok, your foot hurts).
Step 1 is called "Arrange", because you prepare the test.
Step 2 is called "Act", because you do the actual test.
Step 3 is called "Assert", because you check if you were right.
In programming, the programmer just writes the story, as I have it explained to you, but in a language the computer understands. It's the computer that actually does the 3 steps. That's why these tests are called "automated tests".
If what actually happened in step 3 is what you expected to happen, we programmers say "the test passed". Otherwise, "the test failed".
So did the test with the china doll pass or fail? Right, it failed. Because it did not break.
We call these particular tests "unit tests", because we test a single thing. Most of the time something that is small. Like your sister's doll. And there's a lot more to break aeh test.
Continuing with this analogy, I'll introduce mocking and its importance.
So you're pretty confident that the doll will not survive a drop onto your sister's floor, and you really want to test this. The problem is that your sister has friends over and her door is locked, so you can't actually go in there to test it. But you did already manage to steal the doll.
You know her room has wooden floors, but is usually covered in clothes. So you go to your room (which you normally keep very clean) and start throwing some clothes around. This way, you can test drop it in your room knowing that it would have the same effect as if you were to drop it in hers.
But this gets you thinking. Instead of throwing clothes on your floor, what would happen if you threw pillows around? Or dropped it onto carpet or tile instead. So you set up a series of situations where you drop the doll onto floors of these different types, but you do it in a very controlled manner so you know the only thing that changed from one test to the next is the floor.
I think this characterization of BDD is not quite right. I believe that BDD also emphasizes testing first, although they use some different terminology (like behaviour vs test) and maybe alter the emphasis of some things.
Hi Hila, the nice thing about TDD is that it's a clear and well defined concept. You write a test. Test fails. You write the code to pass the test. You refactor to clean things up. You write another test, and so on.
What about BDD? Well, I am not an expert, but I see BDD as kind of a generalization, maybe an extension as well. For one thing, BDD doesn't usually use the word "test" even when talking about what is essentially a unit test. BDD tries to emphasize the desired behaviour of the application, and as such it encompasses both what we'd call "unit" tests, i.e. small-scale tests of logic, as well as maybe "integration" tests, i.e. higher-level functionality of the system as a whole.
I get a sense that some of BDD is not so much about writing code as it is about opening communication channels between developers and people who are driving the requirements, such as users, business people, or managers.
I don't think that BDD is as well-defined as TDD, and as such there is potentially more room for confusion or disagreement.
Usually the term "legacy code" refers to an older codebase that’s still in use but the technology is considered somewhat outdated and therefore poses greater maintenance difficulties. It does not seem to be related to BDD though. If your question was related to BDD somehow, please clarify.
It's not related to BDD. Legacy code has many definitions, so I wanted to know what's yours :)
My favorite definition is:"Code you are afraid to change".
The baseline of Unit testing is that it tests every piece of code in isolation without dependencies.
Let's understand it with the example of making a breakfast, e.g.Omelet.
Here you check the quality and quantity of each ingredient to make a delicious Omelet.
Here you are checking each ingredient separately without mixing them. You’re doing a unit testing in this sense. You’re testing your work and units that will comprise the product.
But note that you’re not testing the product.
Now, let's say you found eggs unhealthy. Here you know that those eggs are going to ruin your morning and hence you will replace them with fresh eggs. That's the main benefit of unit testing where you can identify the piece of code which will cause a problem in future.
When you taste the omelet, you are doing Integration testing. Integration testing checks that whether all the components work together as expected.
P.S: Those who are older than five and want to dig more about Unit testing, can read this blog: simform.com/unit-testing-tdd
I really like this answer!
This one wins. Thank you.
You think that your sister's china doll, that you hate so much, breaks when you drop it on the floor?
How would you find out if that is really case?
You would probably:
Step 1 is called "Arrange", because you prepare the test.
Step 2 is called "Act", because you do the actual test.
Step 3 is called "Assert", because you check if you were right.
In programming, the programmer just writes the story, as I have it explained to you, but in a language the computer understands. It's the computer that actually does the 3 steps. That's why these tests are called "automated tests".
If what actually happened in step 3 is what you expected to happen, we programmers say "the test passed". Otherwise, "the test failed".
So did the test with the china doll pass or fail? Right, it failed. Because it did not break.
We call these particular tests "unit tests", because we test a single thing. Most of the time something that is small. Like your sister's doll. And there's a lot more to break aeh test.
Continuing with this analogy, I'll introduce mocking and its importance.
So you're pretty confident that the doll will not survive a drop onto your sister's floor, and you really want to test this. The problem is that your sister has friends over and her door is locked, so you can't actually go in there to test it. But you did already manage to steal the doll.
You know her room has wooden floors, but is usually covered in clothes. So you go to your room (which you normally keep very clean) and start throwing some clothes around. This way, you can test drop it in your room knowing that it would have the same effect as if you were to drop it in hers.
But this gets you thinking. Instead of throwing clothes on your floor, what would happen if you threw pillows around? Or dropped it onto carpet or tile instead. So you set up a series of situations where you drop the doll onto floors of these different types, but you do it in a very controlled manner so you know the only thing that changed from one test to the next is the floor.
Shortly, unit tests are methods that test small pieces of your code, for example, one specific method.
They are written mostly by programmers in order to ensure that their code works before writing the next piece of code.
There are two main approaches for writing unit tests:
BDD - the programmer writes the code and then writes the test.
TDD - the programmer writes the test and then writes the code.
I think this characterization of BDD is not quite right. I believe that BDD also emphasizes testing first, although they use some different terminology (like behaviour vs test) and maybe alter the emphasis of some things.
Thanks for the comment!
What is the full definition of BDD in your opinion?
Hi Hila, the nice thing about TDD is that it's a clear and well defined concept. You write a test. Test fails. You write the code to pass the test. You refactor to clean things up. You write another test, and so on.
What about BDD? Well, I am not an expert, but I see BDD as kind of a generalization, maybe an extension as well. For one thing, BDD doesn't usually use the word "test" even when talking about what is essentially a unit test. BDD tries to emphasize the desired behaviour of the application, and as such it encompasses both what we'd call "unit" tests, i.e. small-scale tests of logic, as well as maybe "integration" tests, i.e. higher-level functionality of the system as a whole.
I get a sense that some of BDD is not so much about writing code as it is about opening communication channels between developers and people who are driving the requirements, such as users, business people, or managers.
I don't think that BDD is as well-defined as TDD, and as such there is potentially more room for confusion or disagreement.
Some links:
Thanks!
what about legacy code? what is your definition for that?
Usually the term "legacy code" refers to an older codebase that’s still in use but the technology is considered somewhat outdated and therefore poses greater maintenance difficulties. It does not seem to be related to BDD though. If your question was related to BDD somehow, please clarify.
It's not related to BDD. Legacy code has many definitions, so I wanted to know what's yours :)
My favorite definition is:"Code you are afraid to change".
I would throw a curve ball in the explanation.
Unit testing is like being a quality control officer. Regardless of the different ingredients in a cake, it should always taste the same.