I search a lot but couldn't find any right answer for this question. Some articles define TDD which you can do any sort of test in it. Some articles just said TDD is just about function test, and when it comes to acceptance test it will be BDD not TDD. So...
Is TDD really just unit test?
There's no universally accepted definition of what a unit test is, so it follows that there can't be a universally accepted answer to that question.
Modern-day TDD is an invention (or rediscovery) of Kent Beck. If you read his book Test Driven Development: By Example, you'll see that he uses small deterministic tests without dependencies. This is a common way to do TDD, and seems to fit most people's definition of a unit test.
On the other hand, just because Kent Beck originally used unit tests to demonstrate the TDD technique, it doesn't exclude other types of tests. Another great resource that uses a slightly wider kind of test is Growing Object-Oriented Software, Guided by Tests by Nat Pryce and Steve Freeman. While they don't use Gherkin, you can view that approach as congenial with BDD - at least, I'd call it a sort of outside-in TDD.
I once had the opportunity to talk to Dan North (the inventor of BDD) about the overall purpose of these kinds of techniques, and I think that we agreed that the overall motivation is to get fast feedback. With unit tests, you can run a test suite in mere seconds. That gives you almost immediate feedback on your API design and implementation.
If other types of test can give you similar feedback, it fits into the overall motivational framework of TDD. Exactly what you call the tests is of less importance.
But to answer the explicit question:
Is TDD really just unit test?
No, test-driven development (TDD) is a process in which you write (unit) tests and let the feedback you receive from these tests guide you to figure out what to do next. A common TDD workflow is the red-green-refactor cycle.
Is TDD really just unit test?
No
The problem with driving development with small-scale tests (I call them "unit tests", but they don't match the accepted definition of unit tests very well).... -- Kent Beck, 2003
Michael Feathers, writing in 2005
...there is a failure case for teams that attempt to get test infected; you can end up writing very slow tests that take so long to run that they essentially start to feel like baggage even though they help you catch errors.
The important idea was that tests be fast and reliable (so that they aren't hindering the "refactor" task). But that doesn't necessarily mean that the test subject needs to be small.
That said, the tests we are talking about are programmer tests: they are there to support the making of the product code. The tests that support other stakeholders are a different thing, subject to different constraints.
