Tag Info

Hot answers tagged

102

The difference between BDD and TDD is that BDD begins with a B and TDD begins with a T. But seriously, the gotcha with TDD is that too many developers focused on the "How" when writing their unit tests, so they ended up with very brittle tests that did nothing more than confirm that the system does what it does. BDD provides a new vocabulary and thus focus ...


80

The only advantage I can think of for inline tests would be reducing the number of files to be written. With modern IDEs this really isn't that big a deal. There are, however, a number of obvious drawbacks to inline testing: It violates separation of concerns. This may be debatable, but to me testing functionality is a different responsibility than ...


34

I can think of some: Readability. Interspersing "real" code and tests will make it harder to read the real code. Code bloat. Mixing "real" code and test code into the same files / classes / whatever is likely to result in larger compiled files, etc. This is particularly important for languages with late binding. You may not want your customers / clients ...


28

Behavior Driven Development is an extension/revision of Test Driven Development. Its purpose is to help the folks devising the system (i.e., the developers) identify appropriate tests to write -- that is, tests that reflect the behavior desired by the stakeholders. The effect ends up being the same -- develop the test and then develop the code/system that ...


27

attempting it in the fashion of TDD, will merely make it a maintenance nightmare and impossible for the team maintain. You can't win that argument. They're making this up. Sadly, you have no real facts, either. Any example you provide can be disputed. The only way to make this point is to have code which is lower cost to maintain. Furthermore, ...


27

It's comparing oranges and apples. Integration tests, acceptance tests, unit tests, behaviour tests - they are all tests and they will all help you improve your code but they are also quite different. I'm going to go over each of the different tests in my opinion and hopefully explain why you need a blend of all of them: Integration tests: Simply, test ...


22

It is equally realistic as it is unrealistic. Realistic If you have automated testing that has been shown to cover the entire code base, then insisting upon 100% coverage is reasonable. It also depends upon how critical the project is. The more critical, the more reasonable to expect / demand complete code coverage. It's easier to do this for smaller to ...


20

TL;DR: As long as it meets your needs, yes. I've been doing Acceptance Test Driven Development (ATDD) development for many years now. It can be very successful. There are a few things to be aware of. Unit tests really do help enforce IOC. Without unit tests the onus is on the developers to make sure they meet the requirements of well written code (in so ...


18

I have seen it. Didn't end up well. I think that cucumber is cumbersome (<--lol :D) abstraction for this exact reason. Too hard for non-technical people to write by themselves; too verbose for technical people. Non technical people just haven't learned to think like programmers. It is our privilege to understand abstract knowledge, break it down, ...


16

A few of my thoughts: Be honest that writing automated tests will take more time. If you're doing unit level TDD (which I would recommend as a starting point if you're going to invest in automated testing), you can expect about 30% extra time needed to code a feature. The key here is explaining that this extra 30% (which is probably higher than 30% in ...


16

Developers are very, very good at abstraction. If you give us half a problem, we'll come up with the whole solution. In fact, we're so good at this, we won't even notice that we've only got half the problem. We're "solution space" people. Our job is to solve problems. Testers, on the other hand, are "problem space" people. They're the ones who ask, "What ...


15

Maybe I'm too old-fashioned, but even the most modern development or proccess techniques cannot substitute another set of eyes, fresh eyes, before releasing a product to your client. Even if your product is simply an API for another developer, you can use QA to think as the API user, providing test/use scenarios that you or your client did not think in ...


15

In most cases, 100% code coverage means that you've "cheated" a little bit: Complex, frequently changing parts of the system (like the gui) have been moved to declarative templates or other DSLs. All code touching external systems has been isolated or handled by libraries. The same goes for any other dependency, particularly the ones requiring side ...


14

BDD utilizes something called a "Ubiquitous Language," a body of knowledge that can be understood by both the developer and the customer. This ubiquitous language is used to shape and develop the requirements and testing needed, at the level of the customer's understanding. Within the confines of the requirements and testing dictated by BDD, you will use ...


13

BDD adds a cycle around the TDD cycle. So you start with a behaviour and let that drive your tests, then let the tests drive the development. Ideally, BDD is driven by some kind of acceptance test, but that's not 100% necessary. As long as you have the expected behaviour defined, you're ok. So, let's say that you're writing a Login Page. Start with the ...


12

Well, I have used the TDD like approach to let the tests / requirements evolve the design of the program. The problem was that over one half of the development time as for writing / refactor tests Unit tests work best when the public interface of the components they are used for does not change too often. This means, when the components already are ...


11

It is very unrealistic theortically and impractical in a business sense. It is unrealistic with code that has high cyclomatic complexity. There are too many variables to cover every combination. It is unrealistic with code that is heavily concurrent. The code is not deterministic so you can't cover every condition that might happen because behavior will ...


11

For many of the same reasons that you try to avoid tight coupling between classes in your code, it's also a good idea to avoid unnecessary coupling between tests and code. Creation: Tests and code may be written at different times, by different people. Control: If tests are used to specify requirements, you'd certainly want them to be subject to different ...


11

Actually, you can think of Design By Contract as doing this. The problem is most programming languages don't let you write code like this :( It's very easy to test for preconditions by hand, but the post conditions are a real challenge without changing the way you write code (a huge negative IMO). Michael Feathers has a presentation about this and this ...


10

Here are some additional reasons I can think of: having tests in a separate library makes it easier to link only that library against your testing framework, and not your production code (this could be avoided by some preprocessor, but why to build such a thing when the easier solution is to write the tests in a separate place) tests of a function, a ...


9

They're not really tests; they're scenarios or examples of how to use your code. If you avoid the word "test" you'll have an easier time, and it will become obvious that 2 is the way forward because you'll be able to discuss your scenarios with the business. The business have no interest in tests phrased in the way you've described in 1. Business people ...


9

100% code coverage for unit tests for all pieces of a particular application is a pipe dream, even with new projects. I wish it were the case, but sometimes you just cannot cover a piece of code, no matter how hard you try to abstract away external dependencies. For example, let's say your code has to invoke a web service. You can hide the web service ...


9

Your order is wrong, methinks: Define Acceptance Tests that fail Define Unit Tests that fail Make Unit Tests pass by writing the logic required for the feature Make the Acceptance Test pass by integrating the logic into the existing system Repeat with the next defined requirement Basically, in both TDD and BDD, you always define what your new code ...


8

100% coverage is not the same as 100% tested. I'd see a QA person in a ATDD project as someone that would help write the tests and perform the other types of testing that still exists. I.e. UI Testing, destruction testing and load/stress tests. But I've never worked out an ATDD project.


8

You're probably getting push-back because you are viewing (and therefore communicating to your team) the two as mutually exclusive, and they aren't. What you have in place is a good model. It would be a mistake to "abandon" something that works. Fortunately TDD is just about when the test specifications are written. It doesn't mean the testers write the ...


8

Part of the difficulty in terms of the customer writing a specifications document is that the customer often doesn't know how to translate the things the customer wants into a language which actually describes what the customer needs. While the customer may say that they want a certain behaviour to exist in a system, they are generally not so concerned with ...


8

For an impressive, real world example of 100% branch coverage, see How SQLite is Tested. I realize your question specifically asks about javascript which is an entirely different type of software product, but I want to bring awareness to what can be done with sufficient motivation.


8

It might be useful to see a picture: Note that acceptance tests (i.e. verification) sit outside of the usual TDD cycle. The unit tests insure that your code works, but the acceptance tests insure that the code meets the customer's requirements. ATDD stands for Acceptance Test-Driven Development.


8

Only Test if it Brings Value I don't test typically, but if I did I certainly wouldn't aim for any percentage number of coverage or loading tests in front of everything I wrote but rather focus on handling of things I don't control and things that were coded poorly that I don't have time to rewrite. If behavior of things I do control and that I did in ...


8

Yes, of course it is. Consider this: a unit test is a small, targeted piece of testing that exercises a small piece of code. You write lots of them to achieve a decent code coverage, so that all (or the majority of the awkward bits) are tested. an integration test is a large, broad piece of testing that exercises a large surface of your code. You write ...



Only top voted, non community-wiki answers of a minimum length are eligible