Marco Emrich

Author
+ Follow
since Aug 14, 2013
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
5
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
1
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Marco Emrich

Congrats lucky winners! Have fun reading my book, I hope you enjoy it.

And thanks again to JavaRanch for this great opportunity, there are really nice and highly skilled people here!

Marco
Thanks Burk,

I really enjoyed the discussions with you!
Hi Jon,

Jon Swanson wrote:
Is there anything about BDD that might be appealing specifically to the people that specify requirements (or not) beyond the arguments in favor of test-driven development?



Sure.

* BDD is about communication. Executable specs make discussion a lot more unambiguous. They help you to get a very clear idea, what a feature should do, before you invest time coding it (code you might have to throw away or change with a high effort otherwise). Additionally this clear idea should be nearly identical in the heads of all team members. While, in the other case, you often have to wait for the implementation to get everyone on the same page.
* The specs document the running system quite nicely and they never go out of sync with the real code, because they are executable and self-verifying.
* Additional practices like Deliberate Discovery and Real Options help to keep the cost low and the software flexible. (Ok - this is not a spec-based argument)

I understand, this is a difficult situation. It's always hard to convince people. Actually, I would rather suggest to start with TDD (you could use the BDD vocabulary and call it BDD just for yourself. You could do it just for your code only. Your colleagues will see the benefits you get and might change their mind. Just telling them that BDD/TDD is better ... I don't believe this will work

On the other hand, I'm not in a position to judge. If the prototyping approach works well for you, maybe you shouldn't completely throw it away. One thing that is often easy to implement on top are automated tests as an after thought (i.e. not TDD). The don't provide any additional benefits, but they lower bug rates and increase quality at the expense of some development time. That is something management usually understands From there, it is not such a far way to go to real TDD.

Good luck with your effort,
Marco
10 years ago

Burk Hufnagel wrote:Does that seem reasonable?



Sure, it's very reasonable.

I think it's a balance thing. If you are don't have maintainability worries with you high-level specs and they execute fast enough - I see no harm doing it this way.

In case you are interested in our (company) approach: It's threefold:

1. We have some end-to-end specs, to mitigate the risks of the integration issues, you mentioned. But we want to keep the number of them low, because we have maintainability issues
2. We have high-level (acceptance) specs, directly on the business logic (domain model)
3. We have tons of low-level (unit) specs on business logic, but also on gui behavior (for some widgets). This means we have some gui specs, but they verify the gui behaviour only and are completely decoupled from business logic.

This works well for our current project. Each project (also team and environment) has of course different needs.

Burk Hufnagel wrote:
Unit tests (for TDD) and specifications (for BDD) are different in that specifications are at a higher level of abstraction.



Hi Burk,

you can define this for yourself if you want. Everyone, has his/her own definition of BDD these days It is, however, not the way Kent Beck, Dan North, and so on see BDD. You can easily have High-Level Tests in TDD - called acceptance or customer tests there. There is even the ATDD methodology working on that. On the other hand, you can use BDD on unit test level quite easily too, specifying fine grained specs. I do this a lot in my book. BDD usually starts at the outside, doing outside-in development - but this is no absolute "must have" and is also done within the "London School of TDD" (see the Book from Nat Pryce).

The differences between BDD & TDD is a heated discussion. Therefore I spent a complete chapter on my book about this topic ("What is BDD?")
10 years ago

Ashish Dutt wrote:This is what i would like to know, how can BDD help me to model the intention of the user?
But what confounds me now is, how will i model and test the "intention" of the user in the light of BDD approach with Javascript?



Hi Ashish,

I'm not sure to understand your question right. How do you define "intention of the user"? For me, "Intention" means "what does the user really want to do". This could be something completely different from the actual behaviour of an application. Hopefully there is a large match. Honestly, I think BDD won't help you here. It's the responsibility of a product owner to gather and define the correct requirements (matching user intention). BDD helps you with the next step: Writing down the requirements as specs in an unambiguous and executable form.

10 years ago

Burk Hufnagel wrote:
Which reminds me, some testing frameworks allow the author to tag a test and then just run the tests with that tag - so you can have tests tagged with labels like '@Fast', or '@Slow-DB', so the test runner can run a subset of the test suite then (if those tests passed) run the rest of the suite. Does Jasmine support that? If not, are you aware of another framework that might?



Actually, we do exactly that to create various stages in our Jenkins-Build-Pipeline. It's, however, not Jasmine in this case. It's a ruby application with the RSpec bdd-framework, which supports spec tagging. The Jasmine-specs for this project (there aren't many) disguise themselves as RSpec specs and run within the fast-stage. The remapping of the runner output is done by the Jasmine-gem.

I'm not aware of any JavaScript BDD framework, that provides spec tagging yet. Maybe it's time to write a Jasmine-plugin
Thanks pointing it out, Burk! I updated the README.
Sorry, for my black/white statement. There are of course, situations and projects where building specs on top of the gui is worthwhile. I just wouldn't want to give the impression that BDD is mainly about GUI-testing.
Hi Jeff,

You can find all code examples from the book at my github account:

https://github.com/marcoemrich/bdd_book
Hi Burk,

exactly! The specs usually execute very fast. And even in the case, they do not - I strongly recommend going through CI server. If you have a slow suite, you should build various stages (e.g.. a low level and a high level stage - with the slower high level stage only running, if the first stage was a success). Just google on build pipelines and Continous Delivery. There is a lot of information available how to setup this stuff. We use Jenkins in our company, but I also heard a lot of good things about JetBrains Teamcity.

If your tests/specs takes more than about two hours to run, you really have other problems In this case I would invest time in optimizing them first.

Do you do GUI tests with different browsers/emulators - for your Sencha Touch stuff?

Burk Hufnagel wrote:The article sounds interesting - could you supply a link to the magazine's site?



http://webandphp.com/

Surfing the web, there seems to be vareity of tools out there for BDD. Are you weighing them or prefer one over the other ? Any recommendations in your book ?



In the book, I use the Jasmine framework. And yes, there are also some more recommendations in the book. If you don't have any specific need, I would suggest to go either with

* Jasmine

or

* Mocha

Jasmine is easier to setup, while Mocha is more flexible. Both are great and provide a rich ecosystem.
Hi Mahtab,

sadly, there is no simple answer to this questions. Behaviour Driven Development means different things to different people. I dedicated a whole chapter of my book to this question. That said - Burk's answer is really good. It covers the very essence of BDD.

BDD means understanding how the program is supposed to behave



That is something we all can agree on - I think. The opinions, on how behavior is going to be verified ... differs. At least, I would say the GUI is not very important. We usually have some end-to-end acceptance tests to verify system integration. Most business logic, on the other hand, is specified directly with the domain models. Writing too much GUI specs tend to become very brittle and hard to maintain ... very fast and early in the project.

hopefully this makes it a bit more clear,
Marco
Hi Fei,

Burk and B. Katz already covered the most important aspect: BDD is mostly about communication! - therefore, reducing misunderstanding and rework. I absolutely agree with that.

I would like to add, that TDD is still a big part of BDD. BDD just changes the vocabulary a bit. Testing sounds like an afterthought, Specs have to be written beforehand

BDD also doesn't need to take a lot of time before your first line of code. You usually do a specification workshop with the team, to gather some requirements. But you need these requirements anyway and writing two or three specs to get you started shouldn't take you more than several minutes. You only need some high-level specs and shouldn't fixate them all upfront. Meeting and talking often is the key, like in all agile processes.

Marco
10 years ago