I was questioning myself about the level of competence you should have to use TDD method. Lets say I want to develop a website in Django, but I dont have any knowledge on developing website nor Django. In this case, should I use TDD to force myself to follow a straight way of coding ? Or will I just totally lose myself on the tests, not understanding what should I test and why.
And if I have an excellent knowledge on Django, does TDD still useful ?
TDD (Test-Driven Development) is not about testing. It is about components design. The words "test driven" are attributes of "development". They describe the way the component design and development are done: by writing use cases (aka "tests" but the word "test" in "test driven development" and "unit testing" is misleading).
To answer the question, the sooner, the better. But you will perceive it as a chore until you reach some level of maturity in software design. It has nothing to do with your competence or proficiency in a language or another.
Related
I am coming from a TDD mindset into BDD. I understand that using BDD is to focus on ensuring the behaviours and business goals of software are being met.
What confuses me is that if I start using BDD in place of TDD, it seems I'm not able to test at such a low-level. For example, when writing a test with a TDD mindset, I might test that properties have been attached to the scope:
it('should attach properties to scope', function () {
expect(MainCtrl.items.length).toEqual(1);
});
In doing this, another developer knows the assignment to scope was expected and required for future use, saving them some debugging should they have removed the assignments or changed defaults etc.
This example doesn't define a behavior so can't be considered BDD. Of course, I could rewrite the test description to make it more behavior orientated, such as, "when the page loads, setup properties for later use so the user can do so and so..." but this seems too abstract.
Is it a done-thing to use both TDD and BDD at the same time? Have BDD available to define the behaviors for all parties involved in the project (including non-technical) and TDD specifically for developers?
Short answer, yes.
However, the distinction between BDD and TDD is not as you've mentioned and I'd like to clear up what "ensuring the behaviours and business goals of software are being met" really means :)
BDD precedes, envelopes and goes beyond the development stage. BDD is far more than a syntax and not just a change from the word "test" to the word "should". BDD is actually a paradigm to writing software that involves the end-to-end business. This page explains that:
BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.
BDD starts with deliberate discovery, where a group of people get together and flesh out the details of a story using scenarios. The group of people is typically made up of 1+ of each of the following disciplines: product, development and QA - also referred to as the three amigos. This exercise precedes development and is very good at identifying defects before you even start development and it creates better specifications through a shared understanding.
Once you have a good story with good scenarios, you can drive development using an outside-in testing approach:
This means you start with the acceptance test (avoid the UI if you can), and as you drive development into the system, you employ TDD at the integration and unit levels for things like your services and domain objects. Here you can choose any syntax you like, and what you have used above with "should" is fine.
If you're using Javascript, we created an open source tool called Chimp to make the process of outside-in testing easy.
Finally, I recommend you look at the following links:
Specification by Example
Shallow Depth of Test
I want to know that,does BDD just work in acceptance test level? If not, does it work in unit test level as well? Does BDD have any suggestion For Unit tests?
thank you
BDD is just a way of defining the specifications for an area of functionality. The idea is to bridge the gap between technical and non-technical people by using human readable syntax of some kind and to use specific examples to define the desired behaviour rather than talking in the abstract. As such it is a tool to help people work together and define the business' requirements for the new functionality. This is the primary point of BDD. Not testing.
The definitions that come out of BDD are however, useful for acceptance testing as they define the expected behaviour that was agreed upon. As such many great tools like cucumber are available to facilitate automation of these scenarios to cut down on your testing time.
With regard to using BDD for something like unit tests, the idea of using BDD and non-technical descriptions is to help involve non-technical people. If there are no non technical people involved in the creation of your unit tests (which I guess is the most likely case) then why bother with it? Technical people can read unit tests that are properly written, just fine. The unit tests that you're writing will come out of the functionality that is described by your BDD scenarios anyway.
However, if there is some technical detail of what you're working on that you're having trouble describing, and your team are comfortable working in a BDD way then definitely give the non-technical language and specific examples approach a go. I just wouldn't bother using the the human readable language version of the example in your unit test.
Edit: After reading xmojmr 's comment about your question, I can absolutely see the benefit of using BDD tools and syntax to make your unit tests more readable/easier to plan out, but I think this is quite different from BDD in general, which is more about bridging a communication gap.
BDD actually started at the class level. The first incarnation of JBehave was a replacement for JUnit that avoided the word "test". It was only later that the system-level stuff came along after Dan North explained mock objects to Chris Matts, an analyst at the time who was learning how to code.
These days, even unit testing frameworks don't insist that you start your test methods with the word "test", and the frameworks for the dynamic languages are pretty much derived from RSpec, which was a port of JBehave's early functionality to Ruby anyway.
So, yes, it's perfectly possible to do BDD at that level.
Of course, alannichols is right in saying that the audience is different, being non-technical.
So why would you want to do BDD?
As Dan says in that first link, it turns out that talking about behaviour is more useful than talking about tests. In BDD, we just avoid the word test. We prefer talking about examples and how things should behave rather than pass or fail.
By having conversations around the desired behaviour of a system or class, and providing examples of that behaviour, you can explore it more easily than when you're talking about testing.
However, because it's a non-technical audience, I find it's enough to put the "given, when, then" in comments. You can see an example here. You don't need an explicit BDD tool.
If you can't find another dev to talk about the behaviour with, I suggest you find a rubber duck.
I a bit familiar with rspec [Ruby] and specs [Scala]. Yesturday I passed a tutor for Cucumber. What I disliked about Cucumber is that additionally to describing scenarios (like you would do with spec- or xUnit-style testing) you have to implement extra layer of indirection: translating scenario steps into ruby expressions. For me creating unnecessary (?) extra layers of indirection feels like "heavy-weight" J2EE-way, not like "light-weight" ruby way. Is understandability by "domain experts" the only advantage of Cucumber? Or is there some non-obvious (technical?) advantages for developer/tester as well?
BDD, from a practical standpoint, is highly synonymous with TDD. Rspec is a BDD test framework, as well as Cucumber.
That stakeholders can read and understand Cucumber acceptance specifications is certainly a key advantage, but this fact alone really doesn't get at the real benefit of Cucumber. Your features and scenarios ought to grow somewhat in specificity as the work being done for them moves through the value stream of your team's development cycle.
Some teams may have an analyst scoping out work at the beginning of the cycle. Sometimes this analyst writes gherkin acceptance specifications, but whoever writes the first draft, you would expect them to be fairly coarse grained. They may not cover every un-happy path.
As the developers take up the work, they often discover edge cases and missing scenarios. At this point they can touch base with the analyst, and the results of such conversations should be written into the cucumber features.
In my experience the testers have cultivated an even more critical eye, and thus it is not uncommon to see them add even more scenarios and features. The testers may also uncover defects, which should be added to the cukes to protect us from regression.
The point is that, in addition to providing executable documentation for our code, Cucumber also provides a repository for the state of the team's conversations vis a vis the features being developed.
There is certainly extra overhead to all of this. However, it's worth considering how much overhead is already in your team's process, which Cucumber might serve to streamline. I find that Cucumber helps reduce the amount of thrash that happens in communication about features both within and outside of the team room.
I should also mention that cucumber is intended as full-stack acceptance testing, and therefore should be less fine-grained, relative to your unit tests. And cucumber is not a good substitute for unit and integration tests. I also would never recommend using cucumber to verify aesthetic aspects of your app's UI. Just use it to validate the actions which a user might take when using your app.
Cucumber is designed to help engage business stakeholders in refining developers' and testers' understanding of the system by collaborating to create scenarios that everyone can understand.
The act of engaging business stakeholders pays off because everyone gets a better understanding, they start sharing the same language and carrying that language into the code (see Domain Driven Design's "Ubiquitous Language"), which can lead to better estimates, appreciation of scope, conversations around options for achieving the same goal, etc. etc.
There are certainly other ways of achieving the goals. For instance, on our C# project we talk through the scenarios, write them on a wiki then implement them using a little custom Domain Specific Language rather like this one. The same thing could be done in Ruby.
BDD is the process of learning the places where we thought we knew what we were doing, but it turned out we were wrong - the discovery of ignorance. With Feature Injection and unit-level examples, this happens at multiple levels of granularity, all the way up to the project vision itself. It tends to pay back for itself, but you don't need a BDD framework to do BDD.
The conversations in BDD are the important bits, not the tool you use to capture them (I helped write JBehave and still believe this is true). Automating regression tests is also important to cut down the manual effort which rises as the codebase grows, and Cucumber, DSLs and other BDD tools give you this as a very nice by-product which also help you trace, and drive out, the shared understanding.
Edit: I should mention that the reuse of steps is also important, but it doesn't make much difference whether you use a BDD framework or a DSL for that. It does make the difference between a DSL and just procedurally mimicking every user interaction.
It depends what you want to achieve.
Cucumber adds overhead, can be tricky to get used to, takes time to master.
If you want your domain experts to be able to read your tests, you should definitely give it a try.
On the other hand, if developers are the only people reading your tests, you can probably stick to rspec/unit-test/etc. and write your integration tests in those frameworks. However you might achieve more readable high level documentation by using cucumber.
See for example rspec 2 core features' descriptions in cucumber.
My question is same as the title. I have not done Test driven development yet,I have performed unit testing and I am aware of testing in general but I hear it is much advantageous to follow TDD?. So should I opt for it everytime or are there some preconditions... i just need to know some basic or important requirements when i should opt for TDD. Sorry if this question is too trivial.
I would say whenever you are coding for a project. By this I mean where you are hoping to produce code that will be used by people. This is basically all code apart from research where you are learning and discovering new techniques.
Even if you think the project is just a small one often things spiral up out of control without care. You wil be glad for the tests when you find yourself having to refactor a big sprawl of code.
Also note that tdd isn't just about testing. It is a methodology of development that encourages you to create clean and solid designs.
As you are starting out tdd everything. Once you have more experience then perhaps you can back off and determine when to not tdd.
IMHO if you are not comfortable with TDD, trying to apply it in projects where you will need to interact/use legacy code it's much more complex than applying it in a project from scratch. In fact, there is a whole book about this.
HTH
My advice would be to use unit testing as often as possible.
Caveat: In my experience TDD works best when working with technologies you already have some experience with. It's often hard to write test assertions if you do not know exactly what the desired result looks like (For example, try writing the test for an ASP.NET MVC action method if you never wrote an action method in your entire life). In those cases you're probably better off writing unit tests after implementing the code.
If I am developing something without a user interface, I always use TDD these days. After all, you have to test the software. You can either do the extra work and do TDD, or you can do the extra work and cludge together a user client just for testing. The former tests more completely and in a more repeatable fashion.
Doing TDD against user interface code, on the other hand, hasn't really delivered much value for me. For various business reasons I'm restricted to Visual Studio out of the box for my work, and "recording" tests with VS is a huge time sink, especially when you have to re-record them if you change the UI. I do TDD for the business logic behind the UI, but not the UI itself.
Is the real benefit in TDD the actual testing of the application, or the benefits that writing a testable application brings to the table? I ask because I feel too often the conversation revolves so much around testing, and not the total benefits package.
TDD helps you design your software. The tests becomes the design. By writing the test first you think about your code from a consumer perspective, making a more user friendly and more compact software design.
Also, by applying TDD you typically end up writing your code in a way where you can supply test mocks and stubs. This leads to less coupled software, making it easier to change and maintain over time.
So I guess allot of the talk around TDD is about testing, but by doing that other big benefits follow, such as quality (coverage), flexibility (decoupling), better design (think as the consumer of the API).
The real improvement is that it is a good way to force you to really think through the design and implementation. Then, once you've prepared the tests and written the code, solutions to unforeseen problems appear more easily.
Something that usually happens to me that is a good analogy: When I'm going to post a question to a forum or IRC channel, I like to have the problems well written and fully described, many times the process of preparing a well written and complete description of the problem magically makes the solution appear.
The real benefit of TDD is supposed to be that it allows you to modify/refactor/enhance your application without worrying about whether you've broken existing functionality. The fact that writing unit tests tends to result in loosely coupled code and better architecture isn't necessarily the point of TDD, but I think it's hard to have one without the other.
You can't really experience the benefit of TDD unless you have unit tests with good coverage. In order to do that, you're going to have to write testable code. That's why the two are often used in conjunction or in place of one another.
Automated testing is such a time saver and confidence booster when you are developing a product that you'll ship multiple versions of. With automated tests, you know that you haven't broken anything between versions. This especially helpful when your product is something that people can write add-ons for - you don't want to break their add-ons between versions.
With TDD, you get a good suite of tests as you develop. Without TDD writing those tests is much more difficult.
Michael Feathers has an insightful blog post about this titled The Flawed Theory Behind Unit Testing. Seriously, go read it. The punch line is
All of these techniques have been shown to increase quality. And, if we look closely we can see why: all of them force us to reflect on our code.
but you should read the full post for the context.
Automated testing keeps humans from doing a machine's job.
Test-driven development maximizes the amount of automated testing.
Beyond a certain point, of course, a human is still required. You reach diminishing returns when you try to apply TDD beyond that point.