I've been most last ten years on leading agile development teams and that's one
of the reasons why i'm excited to talk to you about behavior-driven development
tonight it's just go ahead and just jump right in here about what it is a lot of
people have been talking about it mostly coming from the Ruby community and now
it's catching traction in the java community as well and the first thing we
see here the for the short definition of it it's about implementing an
application by describing its behavior from the perspective of its stakeholders
this is from dan north
dan is the guy who first started working on behavior-driven development about
2003 it's probably better short descriptions I've seen but of course
it's much more than that if we look here you know he goes on describing its a
second-generation outside in pull base multiple stakeholder multiple scale hi
automation agile methodology describes the cycle of interactions with
well-defined outputs resulting in the delivery of working tested software that
matters it's a lot of that's a lot of buzz words they're related to agile but
when i do is I'm going to kind of go through each of these briefly and kinda
give you a flavor for what this is in its second generation built on user
stories these are very common way that agile teams are defining their
requirements these days a format that they're in the other one is extreme
programming especially test-driven development acceptance driven test
planning
and continuous otic integration CI covers everything from you know are you
using an ant file or an even file to something like cruise controller Hudson
we're kicking them off on a periodic basis and the completeness of your
testing and then finally domain-driven design now just a curious quick show of
hands who here is familiar with user stories in extreme programming actually
using them
ok that's pretty good how about domain driven design
ok not bad we'll be covering each of these here the next couple of slides and
get on the next one we're talking about an outside-in methodology and this is
pretty common in a few different areas but here we see from our definition
slide we have stories subscribe features from the stakeholders point of view and
then developers deliver runnable tested features software that matters is
getting back the XP concept of saying that if you can't test some you know
software isn't done until it's tested we need to be focusing on the test or your
story as a way to keep your scope together
what's also important is that it also away describes a relationship
stakeholders need to describe what's going on and they need to describe it in
a way that makes sense for the company help prioritize that help get that to
the developers and the developers turn around the drill down into features in
their tool cats and they can come back out and when I mean development here
it's not just java developers we also have web designers QA people and your
agile project management staff so the first thing we go into here is stories
and multiple stakeholder so multiple stakeholders should be defining your
applications behavior and what I mean by should is that I hope that they're
directly defining it each of them represents one or more business domains
within your company
and each of these domains has a particular jargon or particular language
associated with it and throughout this presentation I want to give my refer to
an example fictitious application i call on pay it's a online payments
application people used to send money to each other kind of like PayPal but I to
find my own I don't have to be strictly talking about paypal so here what we see
is that what we're trying to show here in this thing is how the stakeholders
are involved with the on page story content and first we have the product
group now they're talking about customer interactions they have domain expertise
oh probably $MONEY in payments describing what it means to move money
around in different ways people want to move money around they're also very
focused on service level agreements SLA customers and merchants are very
concerned about how quickly does the site not only respond to them but how
quickly can they get data out of it
sales is involved someone development especially if you're out trying to
aggressively market your program early on
you'll probably often live discounts they recruited these and sales programs
and probably have some features getting into that are also involved with s la's
accounting if you're moving money every day they have to be in there reconciling
it
booking the revenue and they also have a lot of audit compliance if you're any
size if you're a public company these days working anything to do with money
you have socks which is sarbanes-oxley making sure you do anything transparent
make sure people are trying to pull the wool over your eyes like in rounded with
a lot of folks in SAS 70 is also another similar set of rules
security is a much more important topic these days it's getting more important
every year we hear a lot about website tax people going in losing a lot of
their consumer data especially with payment sites and Sony was another big
one last year and so
for example at first day we actually had a separate security office in charge of
a lot of this and so the terms you'll hear from there things like
identification or password strong enough
are we encrypting sensitive data in the application so if somebody does break in
that can't read it anyway
are we keeping up with are patches so we're safe from web attacks are we
coding our platforms in the way that makes them less acceptable the web
attacks and then there's other pci compliance that's payment card industry
it's something pushed by visa it is probably coming the focus of much of
these payment Company's actual work they're doing is to make sure they're
building a more secure product and this is where the audits that test that data
center folks are the ones who run your app so there's monitoring have you
written your app in a way that they can tell something good or bad is happening
they're the folks involved with patching if you're going to be bringing on a
bunch of the merchants our customers you have the capacity for it and then this
is the ITIL the information technology library it's a set of best practices
around how you should be delivering your data center services legal as user
agreements feel anguish they could be in there saying hey we want to be able to
update these in real-time influencing what's going in
of course are writing those SLA agreements making sure they're right
customer support their really about have you given us the tools we can use to
debug your appt quickly and help out folks or sea of how their accounts are
because they are also pushed by some pretty hard metrics and then finally web
design if you're on a web application you will be describing a lot of your
features and whatever in webs in UI elements specific web design if you were
a desktop app would be more of the UI gooey type of language but if we can see
here is there's a lot of folks involved there's a lot of knowledge there's lots
of different types of knowledge involved here getting this out and these are the
types of you know
as development those people putting together features the challenge is how
do we come in and work with all these folks and communicate with each other in
part of it is we're expressing them as stories and user stories have been
around for quite a while they're pretty popular they were first created as a
planning tool saying how much can I describe a feature and then estimating
off of it
they must have a business value must state it they must be testable we want
to make sure that you know if we can test it we know we're done and they must
be small up just fit in a spring or iteration and the sprinter integration
is a common tool and agile development or terminate a gel development describe
how long are we going to spend on each development cycle Sprint's last anywhere
from a week to several weeks but it really is a focused time you're gonna
get work done and work with your work with your stakeholders these are stories
had another big change on it and they emphasize conversations over
specifications they want the requirements to be in more of a natural
language mic on who came up with this and kind of formalized it actually came
across user stories is a way to capture and estimate work by mistake in the late
nineteenth using the company was busy acquiring bunch of other companies and
he was overseeing a lot of different development groups and without
evaluating the new groups as they were brought in and its own team he felt was
not being managed very well and what he didn't like is that he didn't feel they
were doing requirements the right way so we kept telling the staff can you just
go over and talk to those guys and figure out what they want kind of write
it down and then just do it when I get back we'll start doing it the right way
again and things for him step keep getting busier and busier and he never
really get back to these guys but they kept this practice just writing it down
talking to their customers
well it turns out is this team back that he had originally was all of a sudden
outperforming everybody they had stumbled across something that had
worked better than writing down the traditional requirements back going
through all the sign ops and all these other things they found if you actually
got out there and just work with your customers and your stakeholders can
actually get things doing things would occur more quickly and you were also
probably focusing on the things they really wanted them something they didn't
feel they could describe well in a requirements document one of the common
formats and here you have a narrative that describes feature they have to
bring it up two more stories and your acceptance criteria defined dundas and
we'll get to some examples here in a moment but who writes him while the team
writes them and the stakeholders the SH there they typically they describe the
features in the outcomes
this is what I want and this is what i needed to do and somebody has to start
me usually submit the first draft keyway has a role in that they can help
identify testable context they can look in there and saying well if you deliver
this kind of feature the past we've tested in this way or we have some other
datasets we can use so they're there to help out the stakeholder to development
provides scoping estimates we need to make sure what we're talking about can
be actually done within a sprint or do we need to break it up into sub stories
and then all those are supposed to use this ubiquitous language to blend terms
from multiple domain languages the domain driven design comes in where eric
evans read a book around the same time this came out describing that you can
often develop products that fit the users need better if you're talking more
in their domain can be a stakeholders domain or what
everybody we kind of have to reach out to them and figure out the language they
use and then so if we're out we're reaching to a product person or an
accounting person we're learning what they need to do an account comes back
and says hey I need to book revenue i need to look at the transactions then
the developers can come back and they can work with the web design guy and
they can describe it in a language that only uses accounting terms but also web
design terms describe how the features developed and eventually you start
blending in this together where you have a language kind of unique to your
product takes a while to develop but it's here to describe it and it helps to
bridge the gaps in knowledge in other areas between these stakeholders so
let's go ahead and just jump right into a behavior driven story format very
similar to other story formats have been out there we kind of start off here
first with a title but a narrative this is where we're describing the feature
and there's a template for the language you can see it here in bold languages
and ordered to realize the benefit is a roll one feature it's supposed to be
said that kind of easily and casually it shouldn't be did difficult to come up
with your some other facts about here on the other side that we covered
previously then the next thing we talked about is our acceptance criteria and
these are defined in scenarios but there's one this is really the big
benefit behavior-driven development has over other user story approaches is they
came up with a template for acceptance criteria the template is you could say
its own domain language of behavior development driven development but it's
fairly generic what they says here is you know you give it a title and then
you say hey given this set of conditions and you can add more can have more than
one given when an event happens
I expect the following outcomes and you can have more than one out and when you
get down to the acceptance criteria
these are the items hopes get backwards their little bit wrong button the this
is the testicle part here we're going to be testing these scenarios up here we're
describing the benefit what it looks like but it may or may not be testable
but we're going to show how close we can come through these scenarios and you can
have several scenarios describing how this should behave so here's an example
more towards on pay and it's a p2p send money story so p2p is a payments turn
for a person to person and talk about payments online payments are typically
find is p2p person-to-person b2b business to business
c2b consumer business in each of those have a lot of the load of expectations
to a payments person about how that money is moving in the background of
what types of accounts they may have this one will say hey person-to-person
money and here is it in order so the first thing is the benefit in order to
spend less time paying my debts in person or by mail as a person i want to
send money to another person online so here the supposition that would be
faster you don't go to the ATM machine operator check and throwing the mail it
should be easier quicker way to do it this is your benefit so if someone says
okay how do you want this feature to work
what are the scenarios you see and down here we have a scenario and it's paper
has enough funds we have another domain specific term paper this is a person
paying the money in here is that given bob is logged into his account page
Bob's obviously a person has an available balance of one hundred dollars
when he enters in the amount field ten dollars
and enter the recipient's feels sooo at localhost and click the submit button in
the send money form the non play updates the account page for Bob with a
ten-dollar pending transaction to see what localhost updates available balance
to ninety dollars and as a payment notification to the account page for Sue
in the notification section so this is pretty specific
we're actually going out and we're describing the action of one person
sending money to another right down to the web design you a widgets UI widgets
on that page we have expected outcome we have some balances that are changing and
we're also talking about different messages that should be showing up in
different areas of a page
this of course is the happy path there's typically interesting a relatively few
of these and many many more negative paths of all the exception conditions
and down there with a hint that the pair the next one is a pair doesn't have
enough funds but this is kind of the basic template and we'll be using this
template as you see here throughout the rest of the presentation this is
something that's going to stay with us
so the next thing we're looking at here is pull based was another one of the
buzzwords up there in the second definition pull based is an agile term
that describes how teams are behaving teams stakeholders in the business is
behaving push-based development is kind of the old-school kind of the old bad
way we talk about things used to happen it's to show the project team and
executives would come in and say we need you to get this done and it's all really
and they would try to do a lot of things make sure what happened quicker they may
have a lot of good reasons but things were just kind of thrown at us thrown on
it's not even like we're thinking about it
pulling is a way to describe a more efficient way to work and also enables
scaling and for this to work
the first thing that has to happen is the stakeholders up for
spend some time reading some stories and they prioritize them by the business
value business value is another way to say very meaningful feature if we don't
have the feature it doesn't work how do i prioritize the features against each
other may have a financial component just may have a component that says if
we don't have if we don't have it we're out of water or it's just a minor
enhancement so instant so we'll let them pick that priority to the folks running
the business will trust them and this clarifies a relative importance of it
and then as they're planning out there sprint and what they can do the team
commits to store delivery based on priority and capacity they actually go
through that Q&A pick out what it is they want to work now what they want to
work on what they feel they can get done and is high priority
somebody may have put in a story that she's too big scope you need to go back
and to negotiate with them maybe create some such stories and those can occur
that way as well when you get good at this practice you can create a deep
backlog and I don't think over this but a backlog is just this list of
prioritize stories more than one team can help you may have some dependencies
in there maybe not all stories are complete can always be worked on by two
teams at once or any group of stories but when this effort has been put in up
front it becomes much easier for people to or from multiple teams to help and
for others to help and pulling here requires outside in communication
remember that first diagram with with the two circles in order for this to
work
the time has to be put into communicate and share with the team's what's
important and what it is I want this also has another benefit is it's also
opening up to the developers that we want you thinking about it too
they're thinking about the features are thinking about how complicated it is
and they're more engaged it's not just pushing on him
it's just not saying just do it through a spec Adam and walk away or throw it
over the wall and walk away
it's beginning to facilitate a communication the conversation often
folks will come in and evaluate other agile coaches and consultants will come
in evaluated team based on how pull are they
and there's a basic pull cycle they look at shareholders ad business value
priority stories to the backlog development pulls the highest priority
stories that can fit into one sprint then development demonstrates completed
stories is rentable tested features to shareholds to the shareholders is a
software that matters and then after this occurs enough the business can
actually pull a collection of these runnable tested features and release it
as an application or is an update so developments pulling out of requirements
out of stories see what it can do and then when they're all completed other
folks can determine is this enough for a nap or for release
ok so now we're going to go back into more the testing and implementing side
of it and this is a very common diagram folks have seen with test-driven
development the test driven development is usually how most developers were
first exposed to extreme programming and other agile concepts the idea is that
first you write a test fails you code then until it passes and then you
refactor and you keep going in this cycle now of course if you reflect you
you may break it and you got a coat again when this first came out I think
Kent Beck's book was in the early 2000s and folks really started getting into it
wasn't uncommon to hear folks were were seeing their defect rates decrease by at
least a third their development time with
going up and became a very very popular thing to do and usually in here you if
you were to use the tools the ones that were most associated with it was aj unit
and then test NGK min soon afterwards
these are unit testing focus tools and became so popular that everybody tried
to do something else with hey it worked good here at the unit level or the
object level where can we use it next
well behavior-driven testing is not unit testing j it was written for developers
it is a great job like we mentioned i mentioned earlier and also really
popularized code by example in a J unit test herb what you're doing is you're
saying I want to describe some essentially behaviors are some
conditions that the code must behave in order to meet expectations using asserts
and other interactions and you go through and you run your tests but when
it come to take it the story testing the tool gets a little cumbersome I know if
anybody here at experience trying to take j unit to apply it to something
else
one person what was your experience like
yeah
okay that's not bad that's pretty good i mean that's kind of what we had to back
nearly 2,000 we wanted to test we didn't call them stories but something on that
same scope and we wanted to write a framework on top of j in it took us
roughly a man here to get the first pass of it out it did pay off in a lot of
benefits but it's quite a bit different and you know you finding things here
that you know test you know they really just speak to developers test names or
method names method names really don't mean much to stakeholders that's an
implementation detail you don't want to bother him about that the most common j
unit test for Eric soon one test for one method call / object lifetime if you had
several test methods on the junit test you want to create that object several
times so if you wanted to build up complicated scenarios he had to do it
within a single method call became a little cumbersome and the reporting it
was great to have that level reporting if you use an ant task and have it sent
you out an email every morning but a developer had to interpret it for you
and this is kind of weird and North was thinking about 2003 when he was starting
behavior-driven development and he really wanted to find a way to improve
behavior test or story testing and this is what he did he comes up with
something called behavior-driven cycle this is actually a fairly common diagram
now within the Ruby community where a lot of this work has occurred
I took it out of the r-spec book not mention the bibliography but the cycle
here says you focus on one scenario and you write a failing step definition
remember back in the behavior driven story we had things called Givens and
hands and when
and then those are steps ok so you start with a given and the first thing you do
is you write a sick feeling example of a given which means you haven't really put
anything inside your method to implement it
or maybe you put in a fail call to make sure it failed and then you do enough
coding there to get it to pass and you refactor it and once you gonna get that
working you step up and you go around to the next step definition so we saw from
our previous stories we could have seven to ten easy step definitions in any
given scenario this is taking the test driven cycle and adapting it to stories
here really
and here's a quick overlooked at j behave now back here if we look I
mentioned two tools j behavior zzb there's another one out there called
coop coop for Duke cucumber for do people java icon guy cucumbers a popular
story runner in the Ruby community ezb is been out there there's not been a lot
of development on it one of the reasons why folks like it is that it's
relatively easy to use compared to j behave behave i feels more mature it's
the one to go with
but there's some initial complexity the beginning in order to get it working
well so in jail behave it is a genuine replacement for behavior-driven testing
and automates it and it does it by first parsing out the stories have been
written and supporting text otd which is open document text format this is the
format that open office uses that google docs can save to that's where they can
support google docs and Microsoft Word even has a format support for TD and how
compatible it is but it's out there this is probably I think one of the more key
features hear of someone writing a framework that has your stakeholders in
mind because
Microsoft Word or google docs are the tools your stakeholders use I don't know
if anybody's head experience here has anybody found anybody from the business
team who wants to write anything on a wiki right you asked to write something
in a text file you find out that they didn't use Notepad you're getting all
these UTF characters in that your parser can't handle you can get into a lot of
bizarre scenarios and that's where supporting this is helpful because it's
more the tools they use it's more the tools they want to use we found back
when we wrote our previous framework we did eventually organize our stories in
these cases on a wiki and the developer is ended up putting them in until we
wrote a word macro i converted a very simple format into wiki's kind of back
that up executing stories synchronously erasing synchronously this is going to
help you if you have a lot of stories out there and how you want to get them
moving and enables outside in development and it really does this by
allowing us to test the stories and demonstrating them back to the
stakeholder integrates with a lot of popular tools and navin eclipse but why
is j unit here and testing g if this is a replacement turns out J unit those two
tools are so successful that they are ubiquitous they are everywhere
if you want to easily integrate into a new environment you find a way to adapt
your tool to run on top of one of these also the j unit assert is a common way
to get in certain language without running into job as assertive over other
items like that it to find a lot of it so one of the better ways to view j
behave its story writer on top of j unit you can use it in different ways which
we'll get into but that's a great way to think about it
the other big claim to fame is that emits stakeholder readable reports so if
you're looking at a web testing
client this is something where you have an application that's off testing an
external website this is what it's going to kind of look like using j behavior
the j behave library on top you have your stories that you've written in here
or anything green is something that the developer needs to provide you have your
test runner going to side here which one you want to use the J behave you can use
Janet's can use springs use testing geez I think there's a few others out there a
second and then you're going to need to get your configuration here going you're
better is going to be the class out there that goes in and kind of ties the
stories the steps and everything together your story master going to help
to find your reporting and then where you'll be spending most of your time is
creating steps steps are implementing those scenarios those Gibbons wins then
sedans in code and then beneath that will make if you're doing web testing
one thing you can do is you can call directly into selenium which is a common
web testing client and you can even use it to drive a browser you can write
firefox and drive chrome or HTTP unit more the brainless browser at that point
can also use it for direct testing this way it's much more the way people have
used a in the past
instead of going after the test going right into your application code so this
is the way they see using it
first off what you want to do is write your story
configuring veteran in your story mapper implement the steps using the BD cycle
run the story and look at your reports so first thing to do is get your steps
going and you want to get your first step in place so if we look here here's
a small java class is called p2p send money steps and that's the name of the
user story we're going to try to get here and get it implemented if you see
here with this given tag we use annotations to log this part of the
scenario to a method or two associated and if we look back at the story would
say given bob is logged into his account page here we're seeing given pair we got
a dollar in front of it
that means we were able to turn payer into a variable gonna be helpful later
but since the first thing we're supposed to do is write a failing test we had to
call of search fail and when we do sin so it's not too fun to run a test right
now I mean you know it's going to fail it's not gonna tell you anything very
meaningful but he you're here you got all this going to say ok I'm ready to go
and write my code and I want to log into the account page but there was something
the story didn't have they didn't tell us how to login it doesn't cover
registration logins account funding or anything telling the unexpected this is
another big way that agile differentiates itself from other project
methodologies is that agile expect you're going to run into the unexpected
not everybody defines everything perfectly upfront in even though this
one you might say is a little obvious you might be something else
so how are you supposed to do this first thing you do is you go back and look at
your options with with your team
you're still focused on delivering that story you want to get that done and so
you have a few options out there you can look at you can create a missing story
and implement to cover the gap you tried mocking missing services and data bit
anybody here from with marking with that concept is that's where you're right
other code you may eventually throw away to help you get around either spending
more time trying to do it right with incomplete requirements the first time
or if the service is just too unpredictable
you just want to make it easier and quicker
that's definitely an option but you really don't want to do the last one you
don't want to return it to the backlog you don't want to come back and say we
can't do it its there's already some time ago we be some benefit so when you
take it back up with your team you can find out maybe somebody else's a little
bit ahead of their work maybe you can get somebody else to come help out
there's other ways to see where we could go so for the purpose of this example
we're going to say hey let's go ahead and create that missing story and
implement but we're going to do it in a different way we're going to create a
new story going to call it registered people story and we're going to define
it only to the extent we need to make our original story work very simple
narrative in order to use on pay as person I want to register for on pay the
scenario is here it's a little bit different but since I was only given
three user elements in the previous story the name the address and and then
an amount in my account
that's all I'm going to associate with this service very simple i may have to
come back and refactor it later but it's going to help me to live
the story and if you look here we have a little bit different nomenclature around
the story we have these angle brackets around these names jay behave has a
feature where if there's a story you need to execute multiple times and you
can prioritize it you can do it and it looks here at the examples table and
these parameters names focus exactly up to those items and Jay behave will
automatically go and run this twice using the values differently in those
rows so you go ahead and bring that up
so here I'm giving shot here i'm showing you what this actually looks like in the
IDE and different items here so here we go with can scroll around this is a.j
behave report and the first thing they show you is of all the things you went
through you see your stories here they give you some nice stats we had three
scenarios we have given story will cover that and we had 35 steps covered in all
those stories and they're all green and if you come over here you can click on
something called HTML
this is where it gets very interesting true this is large enough to read we can
scroll down
ok
p2p send money so this is a story report now as opposed to with j unit report
this is actually using the language we use to describe our stories it's gone
through its read the file and it's put it out we see first one here is our
narrative shows up and we can see some scenarios our first one pair is enough
funds but we have something here called given stories the given stories was are
registered people story we need to execute that first so we had information
about who's logged into the system in order to log them and say they could be
at their login page if we go down here with the narrative here this is what we
saw previously on the story we can come through here and we can see the example
of it in the report framework is put together this nice little table down for
us here so we understand what the parameters are here here it is
describing the execution of the story the purple letters are describing the
parameters that are passed an or things we've turned into variables the green or
is the text that the j behave match are actually uses to match to your steps
will look at that code example in a minute and we do it here for Bob and
we're gonna do it here for soup then we can come through
here's the story we wrote the first time given bob is logged into his account
page has an available balance of a hundred and what by the reading the rest
of it but you can see here we're pulling out these different elements that we
want to use to actually test against our insight or an example these purple items
are the items that we would send over a selenium test client or we would try to
use in our direct code testing that's been parameterised if we scroll down
here a little more we can see we have other scenarios to find negative test
cases one is he doesn't have enough funds
we're going to say one put a insufficient fund message on your page
or if you don't if you negative amount will ask you to make it a positive
amount so here's kind of the high level of the output of what's going on there
and if we gets here into on pay a couple of quick comments here what actually
looks like one of the things you do when you're writing a web tester is you
it typically is its own application it's independent of anything else if you
doing unit testing usually there's a test tree underneath main source here
its just its own app and these are the classes we described in the diagram back
there talking about and better to your being better is what's called on page
stories
it's a simple Java class up there nobody can read it on pay story maps is the
story mapper and then the steps where we actually kind of associate the story to
the code to test is in two steps class where's Peeta peace and money and
register people let me go ahead and bring up with one of these class files
looks like i showed you a snippet in the previous so here if here what we have
looking at is
you're all the annotations describing the different steps and here are the
given tags and how we're matching them in this one here you know has an
available balance of amount amount is there i was hoping i would have the time
to actually get a soul selenium client in there didn't quite a time but this
still shows you the flavor of what's going on you'd write a J unit test the
same way once you're inside these methods where it says log and you can
set up some different values
this is where you're actually in starting to validate your code or
validate your web system remotely the fact that we have some class level very
variables here signifies that you may have scenarios where you're carrying
state between steps
not every step is completely isolated they are dependent especially when
you're filling out the form each entry on that form as a separate step so you
need to carry that together in order to get a on-click event down here at send
money player sends money to oh there's a better one down there somewhere but this
is so here this one here clicks on the button
descended and you may you know find that as you're going through here since these
are parameterize are also reusable if you have a case of 35 steps you may only
have to write 15 of these step methods because they are reusable you can
parameterize something like a button named you could do it for test it's not
only sending money but it could be canceling the former clearing the form
so there is some reuse here the log statement was just a quick way to make
sure everything was parsing out correctly
sure
no selenium was mostly out there about how you could use j behave as a test
client there's no selenium code in this example the selenium Phil would have to
be added in later
all
interaction
now okay that's one that's one danger mention selenium and they're not showing
a real silentium example sure so the question is is she behaved handling ok
let me restart that there does there's there's nothing in here that looks like
it's interacting with the web server so it's jay behave handling that behind the
scenes and the answer is no it's not
we don't see any interaction here because i didn't put that in for the
example what you would see in here is essentially would be a navigator for
your website written in java code using the selenium library it would be doing
things like going out and posting request pulling down account pages
logging in keeping a state and then you would be using the parameters here like
the name for pay or the name for amount to go into add in two forms
yes yes so what's required to make it work if you would need to put in
silentium code right there then use that library it's not quite that slick right
yes
ok so this is really a long file of steps so up here is the first given and
ears is given if you substitute the name in here Bob for payer our first line our
first story was bob is logged into his account page so this would come in in
pair is logged into his account page is the way that would work
ok so the story let's go back to the story real quick i'll bring it up in a
little larger format so folks can see it
hear hear
says yes so it's so it's right there in one of the things i found helpful was I
would actually cut and paste this scenario and put it in comment blocks as
i was writing the steps up because he had to keep going back and forth and
back and forth into your . it is just parsing the template here is how you can
get from a story into java methods and entering the java method you can state
variables and things in there or just instance variables to help match the
interactions between steps and test some functionality other questions yes
it does ok so he's asking this jay behave actually execute the steps or is
it just a notation for the objects in j behave does execute the steps and when
in order to find the code to execute it uses these annotations and your matching
when we're back there on the other page with all the green text in the purple
text it's actually usually regular expressions matching on that green text
trying to line it up it's doing its best job to go through there and associated
and nope it can be you can use spring or you can use j unit or you can use test
Angie as a way to run on top of the net a and an existing framework so you have
your choice they're also supports other dependency containers like pico weld and
their might
ok guys the one from google ok yes
yeah
yeah
yeah
right so the question is can you distribute steps across multiple classes
and can you share contexts you can definitely have different step classes
and what I've seen it used you typically might want to focus your class around
those interactions you could share them but Jay behavior is really just going to
match on and based on those just based on those annotations that text within
them
so if you're have a given in one class and then in another class if you have
context between them then you'll need to make additional calls between the step
classes in order to grab that if that makes mistakes
yeah
yeah
what I'm suggesting here is that
well first off I'm not really familiar with sharing context and Jay behave if
it's possible to be honest right up front but the examples I've seen in the
way I've seen people use it they tend to keep their context within a class
doesn't mean there could be another facility for it and it is possible
that's one of the popular things that you spring for is actually to configure
something called a step factory and you could list all your step classes in
there or pull a minute out based on a configuration but it's essentially going
to go through there and pull them until it finds a matcher finds one that
matches
yes
ok so the question is did the parts are generate this java file from the text
file and it did not
so this is where we so this is in a step file this is where you try to line up
using the and the annotations the code you want to execute with the text in
that story file so it's using regular expressions here with to match the text
inside the annotations with the scenarios in the stories
ok so there's a couple of things here with the question and the first one is a
given in when work together in you giving you have something in one an
event occurs
you've obviously manipulated some objects and now you have another state
I'll take that part of it first there's two steps to it and that's exactly
what's going on
you're given is your initial context it's your setup if you're saying okay if
I have a story i have a beginning and into have a beginning I need to describe
it somehow i'm on a page right maybe i've logged in maybe I've done something
else there has to be a start to a story and that's what the given does and it
tries to do it in terms in this example when a user would see on their account
page
how can i validate I'm in the right starting position for this story the
when describes the feature describes the action describes an activity here the
when kinda really takes off when we enter data and hit click maybe you put
your Givens into the form then you do your when you hit the click button you
have some choice there you can spin it a little differently it isn't that strict
but then the thenns are the outcomes of events are the results and you want to
verify i had the desired effect or I didn't or i know that it should have
been an invalid
fact so it is context event outcome kind of state machine manipulation types is
given the second part was do you think those verbs of for those words of given
and when and then are enough that is i have seen it to be enough there's
certainly things you can't test with those people can come up with scenarios
but its drilling down to that level to where you have predictable setups events
and outcomes and if you can get to that level then this makes sense but the fact
you have an end in there means she can describe a very complicated set of
Givens and a very complicated outcome even a very complicated when part of
this gets back to the domain driven design is that we're going to take
another domain that maybe has a lot of complexity and we're going to just use
describe it using this template is called the behavior domain or with UI
elements in the web design domain and we're going to map that over there the
best we can and then North has been saying he's been pretty successful with
it almost every project you come up with things that can't be automated or things
that can't be tested but I think it's also a reflection of how much work there
might be to do in order to deliver that feature in order to describe it that
specifically but it's still good question here and i'll open it up for
questions again at the end is you know stories storytest their long lived with
unit tests and agile we kind of say well they're up to the developer it's up to
develop better to keep them maintained and if they choose to keep them
maintained or not you know we'll let them make that call
we are going to state it
but if you're in the storytest you've written something a little different
you've written something that is becoming you're becoming your rental
tested feature it's the proof of it it's something you need to keep long-term
many folks end up using them for regression tests automated regression
test suite can be very powerful tool for you
they can also be to take a subset of those and use them for QA build
acceptance tests this is where if you deliver somebody QA want to run us a set
of smoke tests or whatever make sure that builds up to snuff make sure you
haven't broken anything
and since they're long-lived you have to keep them up-to-date and there's other
techniques for brittleness to that help
this is where QA can help looking at scenarios make sure you're not mixing
too many domains together some literature states no more than two
domains mixed in one scenario if you can get away with that few that's something
that can help out the other one is testing low-level code it turns out that
interactions between objects are also behaviors and you can use something like
Jay behavior test some of your lower level code been thinking about this you
know there are some low-level test I'd love to do in j behave and there's some
I would absolutely hate to do NJ behave so fortunate we have more than one tool
out there and use what fits but you would have the option to use the
behavior of 52
and lastly here since we've kind of gone through one cycle here of showing hey we
got a couple of features or story developed for adventure going to go back
to the team and we're going to keep doing this and we have you know
something here now value that works and so one things we can do here with what
we've developed is we can use it to go back and help this the the stakeholders
discover their their desired outcomes or help create more of them and one thing
that's big is to help get them to experiment or to get them to play around
with things and one of the easiest ways to do that is to give them a demo
instance if you have some runnable tested features even if it's not an app
you can still give them a demo instances out there and have them start playing
and using the product you could even do it to the point to where if you know
it's going to take you a few days or a few weeks to implement a first set of
stories depending on your sprint length maybe have a case we can work with the
web designer you can create a JavaScript mark mock-up and they can start playing
with it a bit and deciding if this is something they want or or can improve on
and they can be writing additional stories to keep the backlog prime for
the next sprint
the other way to speed it up and give them a demo is a mock out such as a
market using a mocking library or something like JavaScript instance so
that's really it
