क्या आपको पहले परीक्षण में BDD / TDD करना है?

Question

भले ही मैं एक टीडीडी या बीडीडी परियोजना में नहीं रहा हूं, या मैं कुछ में रहा हूं जो कहते हैं कि वे टीडीडी कर रहे हैं, लेकिन इससे बहुत दूर हैं, ये ऐसी चीजें हैं जिनके बारे में मैं सोचता हूं और जितना संभव हो उतना पढ़ने की कोशिश करता हूं। के बारे में।

वापस सवाल पर। जब आप बीडीडी कर रहे होते हैं तो आपको अपना "टेस्ट" पहले लिखना चाहिए और इसे विफल करना चाहिए, है ना? और फिर उस सुविधा को लागू करें या जिसे आप इसे कहते हैं। लेकिन अगर आप इसे चरम पर ले जाते हैं तो यह किसी प्रकार का टॉप-डाउन विकास नहीं हो सकता है? आप अपने यूआई को देख रहे हैं और कहते हैं, "मैं यह सुविधा / व्यवहार यहां करना चाहता हूं"। फिर आप उस सुविधा को लागू करने के लिए अपने UI को ठीक करते हैं और वह कोड जो UI का समर्थन करता है। इस बिंदु पर आपने कोई व्यावसायिक तर्क या डेटा एक्सेस लॉजिक लागू नहीं किया है, आपने सिर्फ अपना व्यवहार लागू किया है। आप जो परीक्षा दे रहे हैं, उसे लिखने के बजाय आप पहले अपना यूआई कोड लिखें। कुछ मामलों में यह डेटा एक्सेस और व्यावसायिक परत के लिए समान कोड में परिणाम होना चाहिए, क्योंकि आप अपने यूआई कोड का उपयोग यह परिभाषित करने के लिए करते हैं कि आपके व्यवसाय को क्या समर्थन करने की आवश्यकता है।

बेशक, आपको इसे उन परीक्षणों के साथ पूरक करना चाहिए जो यह सुनिश्चित करने के लिए उपयोग किया जाता है कि सुविधा काम कर रही है जैसा कि यह सुविधा में होना चाहिए।

कोई विचार?

Comments

The tests under TDD are unit tests, which drive the module directly, just as if it was through a separate main. In your top-down comment, you are talking about functional tests, which execute the whole program though a single main.

— Macneil

@Macneil: I don't talk about functional test that test the whole program, even thought you're implementing/designing your program top-down you should still implement unit test for all your public code. Just because you do it top-down doesn't mean you can't make different layers abstract so you can isolate all layers by itself.

— Tomas Jansson

@Macneil: This is a common misconception. TDD tests are not unit tests. TDD tests features, which have no set scale.

— Steven A. Lowe

But there is a set scale: the test must execute quickly in TDD. There are tests that must occur that are also out of the scope of TDD. Overall, TDD is a development plan, not a testing plan.

— Macneil

@Macneil: "quickly" is a relative term. The test suite in my last project executes in about 30 minutes. It replaces 8 hours of manual testing. That is "quickly" enough!

— Steven A. Lowe

Answer 1

You are talking about BDD from a high level perspective of testing your UI. Testing is a bit more fluffy at this level than lower down in your Javascript/server side code.

Several books I've read on TDD say you should write code as if the underlying systems exist, and just write enough to get your test to pass. You can write stubs on the server to get your UI behavioural tests pass. Then you start at this stub seam and write some unit tests for your server side code and work your way down to a full implementation.

I often code as if underlying layers exist to get a high level test to pass, it does feel like going down a rabbit hole and extracting many other classes to satisfy the high level test, and then writing tests for these lower levels. As you've already recognised, it helps to keep you focused starting with higher level tests.

As any seasoned programmer knows, there are many layers to software development. I tend to work lower than the UI and think about the data or behaviour my UI needs from the server and start there (maybe because I don't do much UI work these days).

If I'm really honest, extracting a class from the underlying layers means I'm not doing test first but ... within minutes or sometimes hours I'll have a test for that code. This still feel beneficial to me as I helps see where you might need to supply dependencies to a class and honour the single responsibility principle - if it's hard to test, you're doing too much in one place etc.

Comments

I think you are right. This got to me when I tried out ruby on rails this summer, there they have some bdd test that drives the UI which later drives the implementation of the underlying classes.

— Tomas Jansson

Answer 2

Yes! Otherwise, what you get is development-driven testing.

Realistically speaking, however, there are problems that are hard to approach by using "pure" TDD. You could be more productive writing by writing some uncovered production code up front and covering it with tests later (and learning how to approach similar problems with TDD in the future). Look at this technique, which its author called rinse-and-repeat TDD for want of a better term.

Comments

First line is awesome.

— EpsilonVector

Compared to TDD that is true, but doing things top-down should align pretty well with BDD, right? I look at the GUI and specify the behavior I want, sure I don't write the "behavior-test" right away, but I did specify the behavior throught the UI before I implemented it.

— Tomas Jansson

Answer 3

If you don't write your tests first you are not driving development through your tests. Ergo, you're not doing test-driven development!

Comments

To be fair isnt the question more about whether when doing BDD (not TDD) whether we should be writing the test first?

— bytedev

Feel free to substitute "test" with "behaviour". I haven't seen anything to convince me that, at heart, there's much difference between TDD and BDD. Focus, maybe. But the core idea? Not so much.

— Frank Shearar

Disagree with the fact that you aren't doing test-driven development. You aren't doing it according to the definition of the keyed term, but as long as your are developing tests for your code, your code is definitely being driven by the tests, regardless of when you write them.

— alternative

TDD specifically means writing tests before code. If you don't like that, take it up with Kent Beck, who invented the term. Writing tests after your code might drive your code to some extent, but you can still trick yourself into believing you're driving your code design through tests when you're not. And it's harder to write those tests, because you often have to change untested code. Seen it too often to mention.

— Frank Shearar

@FrankShearar I acknowledged that its not TDD according to what Kent Beck said, but frankly I don't care about what some random person said. Its perfectly possible to drive code design through tests without writing the tests first.

— alternative

Answer 4

If you want to work this way, go for it. But it's not test-driven-development.

Answer 5

What you describe sounds much like the Front-Ahead Design approach. Unfortunately, Front-Ahead Design is Alex Papadimoulis' satirical stab at agile methods.

Comments

I was wondering if you know of any articles that fight back at FAD, debunking its satirical stab?

— CL22

Answer 6

Personally, I believe that it is critical to think about testing during the design stage. Its really great having a working implementation, but the only way you can be sure that you have a working product is if you have tested it piece by piece. The way to cover this is by a combination of Unit tests and a skilled QA team working in partnership.

अब आप इस dicipline को अपनी टीम में कैसे स्थापित करते हैं, यह आप पर निर्भर है। टीडीडी एक ऐसी रणनीति है - और एक है जिसमें इसकी जगह है, और अन्य विविधताएं हैं। हालांकि, TDD UI लेआउट को विकसित करने के लिए विशेष रूप से अनुकूल नहीं है।