These days I've read several articles about BDD to find what it is talking about. Now I get a basic understandings, but still not clear about the whole process.
The following is what I think to do in a BDD process:
All the stakeholders(BA, customer, Dev, QA) are sitting together to discuss the requirements, and write the agreed features on story cards. Here I take a "user registeration" feature as example:
As a user,
I want to register on the system,
so that I can use its services
Create several scenarios in Given/When/Then format, and here is one of them:
Scenario: user successfully register
Given an register page
And an un-registered user
When the user fills username "Jeff" and password "123456"
And click on "Register"
Then the user can see a "Success" message
And the user "Jeff" is created in the system
Implement this scenario with some BDD testing framework, say cucumber-jvm, like:
import cucumber.api.java.en.Given;
public class Stepdefs {
#Given("an register page")
public void an_register_page throws Throwable {
// ...
}
#Given("an un-registered user")
public void an_register_page throws Throwable {
// ...
}
// ...
}
for the steps one by one.
But I soon find myself in trouble: there are pages, models, maybe databases need for this scenario, seems a lot of thing to do.
What should I do now?
What should I do now? Do I need to discuss this scenario with all the stakeholders? For BA/Customer/QA, I don't think they really care about the implementations, is it a good idea to discuss it with some other developers?
Suppose after I discuss it with some other developers, we agree to split it to several small parts. Can we make these small parts as "scenario"s with Scenario/Given/When/Then format as what we just did with cucumber-jvm, or can we use JUnit as we normally do in TDD?
1. If choose "cucumber-jvm", it seems a little heavy for small part
2. If choose JUnit, we need to involve more than one testing framework in a project
3. Is it the best if there is a single testing framework to do both things (not sure if there is)
Suppose I choose option 2, using JUnit for the small tasks
The following is what I will do after this decision:
Now we create new small tests to drive implementations, like creating user in database, as we normally do in TDD. (red->green->refactoring). And we don't care the cucumber test Scenario: user successfully register (which is failed) for now, just leave it there. Right?
We develop more small tests with JUnit, made them red -> green -> refactored. (And the imcomplete cucumber test is always failed)
Until all the small tests are passed, we turn to the cucumber test Scenario: user successfully register. Completed it and make sure it turn green at last.
Now develop another scenario, if it's easy, we can implement it just with cucumber, otherwise we will have to split it and write several jUnit test
There are definitely a lot of mis-understandings, even very basic ones. Because I don't find myself gain much value from BDD except the "discuss with all stakeholders" part.
Where is my mistake? Appreciate for any sugguestions!
Don't start with logging in; start with the thing that's different to the other systems out there. Why is someone logging in? Why do they want to use the service? Hard-code a user, pretend they're logged in, focus on the value.
If you focus on UI details you tie yourself to the UI very strongly, and it makes the UI hard to change. Instead, look at what capabilities the system is delivering. I don't recommend using a login scenario anyway, but if I did, I'd expect it to look more like:
Given Jeff isn't registered with the site
When he registers with the username "Jeff" and password "123456"
Then his account creation should be confirmed
And he should be invited to log in for the first time.
Look up "declarative vs. imperative" here to see more on this.
If your UI is really in flux, try out the scenario manually until the UI has settled down a bit. It will be easier to automate then. As you move into more stable scenarios it will be better to automate first (TDD-style).
What should you do now? Well, most people don't write class-level tests for the UI, so don't worry about it until you start driving out the controller and presenter layers. It's normally easier to have frameworks in the same language, but two different frameworks is fine. Cucumber / RSpec, JBehave / JUnit, SpecFlow / NUnit are pretty typical combinations. Do the smallest amount you need to get that first scenario working. It won't be much, because you can hard-code a lot of it. The second scenario will start introducing more interesting behaviour, and then you'll start to see your class-level tests emerge.
BTW, BDD started at a class level, so you can do the same thing with the classes; think of an example of how you might use it, write "Given, When, Then" in comments if your framework doesn't work that way already, and then fill in the gaps!
Yes, your Cucumber scenario will be red throughout, until it isn't.
Ideally you'll be making one last unit test and the Cucumber scenario pass at the same time, rather than just writing a bit of extra code. It's very satisfying to see it finally go green.
The original point of BDD was to get rid of the word "test", since it causes people to think of things like TDD as being about testing. TDD's really about clean design; understanding the responsibilities and behaviour of your code, in the same way that scenarios help you understand the capabilities and behaviour of your system. It should be normal to write both system-level scenarios and class-level tests too.
You're already ahead of all the people who forget to discuss the scenarios before they start coding, though! The conversations with stakeholders are the most important part. You might get value out of including a tester in those conversations. Testers are very good at spotting scenarios that other people miss.
It looks like you're pretty much on the right track where the rest of the process is concerned. You might find some of the other BDD answers in my profile helpful for you too. Congrats and good luck!
I think doing registration/sign_in first is a really good thing to do when you are learning the mechanics of doing BDD. Pretty much everyone understands why you would want to sign into a system, and everyone understands that the system has to know who you are before you can do this, so you have to register first.
Doing this simple task allows you to concentrate on a smaller subset of BDD. By narrowing your focus you can improve quality, whilst being aware that there is much more to learn a little later on.
To write your sign in scenarios you need to focus on two things:
writing scenarios
implementing step definitions
These are the basic mechanics of BDD, but they are only a small part of the overall process. Still I think you'd benefit from working on them because at the moment you are not executing the mechanics very well, which is to be expected because you are new to this.
When you write scenarios you should concentrate on 'what' you are doing and 'why' you are doing it. Scenarios have no need to know anything about 'how' you do things. Anything to do with filling in stuff, clicking on stuff etc. is a smell. When your scenarios only deal with the what and why they become much simpler.
Feature: Registration
A pre-requistite for signing in, see sign_in.feature
Scenario: Register
Given I am a new user
When I register
Then I should be registered
Feature: Sign in
Dependant on registration ...
I want to sign in so I can have personalised content and ...
Scenario: Sign in
Given I am registered
When I sign in
Then I should be signed in
You really don't much more than this to drive the development of a simple sign_in system. Once you have that running you can deal with some sad paths e.g.
Scenario: Sign in with bad password
Given I am registered
When I sign in with a bad password
Then I should not be signed in
And I should be told ...
If you implement things nicely this sad path scenario should be trivial to implement as all the infrastructure is already in place to sign in, all that is different is you are using a bad password.
You can see an example of this at https://github.com/diabolo/cuke_up. The way to use this example is follow the commit history, and in particular notice how I am using the extract_method refactor to take all the code out of the step definitions. Each method I extract is a tool to reused when writing subsequent scenarios. Making an effective set of tools is the key to productivity when implementing scenarios.
Nowadys sign_up is so simple because we can rely on a 3rd party library and their unit tests. This means we can get pretty good results without ever having to worry about the transition to our own code and doing bits of TDD. So for now there really is no need to think about TDD.
So long as you are aware that you are only doing a small subset of BDD, I think you can successfully use this approach to provide foundations for all the extra stuff you have to deal with when working with the things that differentiate your system from others.
To summarize, just focus on
writing simple scenarios
making your step definitions elegant
creating tools (extracted methods) that can be used in the next scenario you write
You have plenty of time to learn the other stuff, and it will be much easier if your basic mechanics are better developed.
I just started working for a company that uses a "Rapid Development Environment" (RDE) supplied by a third party. The idea is that you can specify things like: "display data in grid", "datasource", "sort by" and it generates an a ASP.NET application that does all of those things.
I'm personally not a huge fan for the following reasons:
You are at the mercy of the RDE with
regards to what level of control you
have. For example there is no
try/catch/fail mechanism.
If there is a bug in the RDE there is
nothing you can do, you have to wait
for them to release a fix.
I'm not sure that it speeds things up
all that much.
There is no way you are going to find
someone with X years of experience
using some backwoods RDE. Every new
employee is starting from scratch
You can't integrate many common tools with it. Source control would be an example of this. While i'm sure I could take the EXTREAMLY verbose xml files used to generate the application and manually insert them into Source control there is no way for me to just right click and checkin. Even if I do that there would be nothing meaningful displayed if you do a diff...
Has anyone found these things useful? They seem like a gimic to keep costs down to me...
I don't use any tool/framework/environment/etc that I cannot bypass whenever I want to.
I don't care how good the product looks on paper or what impressing demos I'm shown.
If the product isn't mature and expressive enough to offer the possibility to work around it or hack/plug into it, I'll pass.
I am after some advice and pointers on integration testing for a web app. Our project has been running for a number of years, and it is reasonably complex. We are pretty well covered with unit tests, but we are missing a decent set of integration tests. We don't have documented use cases or even a reasonable set of test cases beyond our unit tests. 'Integration testing' today consists of the developer's knowledge of the likely impact of a change and manual, ad-hoc testing of the app. It is really not ideal - we now want to design and automate a solid set of tests to allow us to perform regression testing, and increase our confidence in the quality of the app.
We have finally built a platform (based on Selenium) to allow us to quickly author and automate the execution of the tests. The problem now: we don't have any tests, the page is well and truly blank. The system has around 30 classes which interact with each other and influence the UI. For a new user signing up, there are about 40 properties that can be set, with each once impacting the experience. Over the user life time they will generate even more states. Given so many variables and possible states, it is a daunting prospect to get started, which is probably why it has been neglected thus far.
The pain of not having a decent set of tests is now becoming destructive. I am dedicating time to get this problem fixed - I am after some practical advice on the authoring of the tests. How do you approach it? Do you have any links I may find useful? How can I stop my mind running away with the seemingly infinite number of states for a user's data? How can I flush out the edge cases which are failing (and our users seeming to be finding)?
If it is the sheer amount of combinations that is holding you back in trying to generate testcases, you should definitly take a look at all-pair testing.
We have used PICT from microsoft as a tool to successfully minimize the amount of testcases while still being reasonable confident to have most cases covered.
the reasoning behind all-pairs testing
is this: the simplest bugs in a
program are generally triggered by a
single input parameter. The next
simplest category of bugs consists of
those dependent on interactions
between pairs of parameters, which can
be caught with all-pairs testing.1
Bugs involving interactions between
three or more parameters are
progressively less common2, whilst
at the same time being progressively
more expensive to find by exhaustive
testing, which has as its limit the
exhaustive testing of all possible
inputs.
I've been working on an app, by myself, and I am at a stage where everything works great--as long as the user does everything he or she is supposed to do. :-) The software needs more testing to see how robust it is, how well it works when people do things like click the same button repeatedly, try to open the wrong kind of files, put data in the wrong places, etc.
I'm having a little trouble with this because it's a bit difficult for me to think in terms of using the application incorrectly. These are all edge cases to me. Still, I'd like to have the application as stable and well tested as possible before I start giving it to beta testers. Assuming that I am not talking about hiring professional testers at this point, I'm curious whether y'all have any tips or systematic ways of thinking about this task.
Thanks, as always.
Well it sounds like you are talking about 2 different things
"Testing your application's functionality" and "Stress testing"(which is the title of your question)
Stress testing is when you have a website, and want to check that it can server 100,000 people at the same time. Seeing how your application performs under stress. You can do this a number of ways, e.g by recording some actions and then getting a number of agent machines to hit your application concurrently.
This questions sounds more like a Quality Assurance question. That is what testers / beta testers are for. But there are things that you can do yourself to validate your application works the best it can.
Unit testing your code would be a good start, it helps you to try and find those edge cases. If your method takes in things like ints, try passing in int.max, int.min, and seeing what blows up. Pass nulls into everything. If you are using .Net you might want to look at PEX, it will go through all the branches/codepaths that your application has. That might help you to further refine your unit tests to test your application the best you can.
Integration tests, see what happens end to end for some of your usual things. This will help you 'find bugs' as you are developing later.
Those are some quick tips on things you can do yourself to try and find edge cases that you may have missed. But yes, eventually you will need to pass your app off to someone else to test. Just make sure that you have covered off as much as you can before it hits them :-)
Make sure you have adequate code coverage in your unit tests and integration tests.
Use appropriate UI validation, and test combinations that can break it.
I have found that a well-architected application that reduces the number of possible permutations in the UI (ways the user can break it) helps a lot. Design patterns like MVC can be especially useful in this regard, since they make your UI veneer as thin as possible.
Automation.
(Re)Factor your code so that another program can throw user-events at it. Create simple scripts of user events and play them back to your program. Capture events from beta users and save those as test scripts (useful for reproducing problems and checking for regressions). Write a fuzz-tester that applies small random changes to the scripts and try them against your program as well.
With this kind of automation you can stress and application and find glaring problems like caches and memory leaks. It won't test the actual functionality. For functionality, unit tests can be helpful. There are a ton of unit testing frameworks out there to try. Pick something useful, learn to write good tests, and integrate them into your build process.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Why should I do Nightly Builds?
You should do nightly builds to ensure that your codebase stays healthy.
A side effect of doing nightly builds is that it forces the team to create and maintain a fully automated build script. This helps to ensure that your build process is documented and repeatable.
Automated builds are good at finding the following problems:
Somebody checked in something that breaks stuff.
Somebody forgot to check in a necessary file or change.
Your build scripts no longer work.
Your build machine is broken.
Doing this nightly ensures that you catch such problems within 24 hours of when they occur. That is preferable to finding all the problems 24 hours before you are supposed to deliver the software.
You should also, of course, have automated unit tests that are run for each nightly build.
I've personally found continuous integration to be better than nightly builds:
http://en.wikipedia.org/wiki/Continuous_integration
I even use it on one man projects, it's amazing how fast you can expose issues and take care of them right there.
I've been doing build engineering (among other things) for 16 years. I am a strong believer in build-early, build-often, continuous integration. So the first thing I do with a project is establish how it will be built (Java: Ant or Maven; .NET: NAnt or MSBuild) and how it will be managed (Subversion or some other version control). Then I'll add Continuous Integration (CruiseControl or CruiseControl.NET) depending upon the platform, then let the other developers loose.
As the project grows, and the need for reports and documentation grows, eventually the builds will take longer to run. At that point I'll split the builds into continuous builds (run on checkin) that only compile and run unit tests and daily builds that build everything, run all the reports, and build any generated documentation. I may also add a delivery build that tags the repository and does any additional packaging for a customer delivery. I'll use fine-grained build targets to manage the details, so that any developer can build any part of the system -- the Continuous Integration server use the exact same build steps as any developer. Most importantly, we never deliver a build for testing or a customer that wasn't built using the build server.
That's what I do -- here's why I do it (and why you should too):
Suppose you have a typical application, with multiple projects and several developers. While the developers may start with a common, consistent development environment (same OS, same patches, same tools, same compilers), over the course of time their environments will diverge. Some developers will religiously apply all security patches and upgrades, others won't. Some developers will add new (maybe better) tools, others won't. Some will remember to update their complete workspace before building; others will only update the part of the project they're developing. Some developers will add source code and data files to the project, but forget to add them to source control. Others will write unit tests that depend upon specific quirks of their environment. As a consequence, you'll quickly see the ever-popular "Well, it builds/works on my machine" excuses.
By having a separate, stable, consistent, known-good server for building your application, you'll easily discover these sorts of problems, and by running builds from every commit, you'll be able to pinpoint when a problem crept into the system. Even more importantly, because you use a separate server for building and packaging your application, it will always package everything the same way, every time. There is nothing worse than having a developer ship a custom build to a customer, have it work, and then have no idea how to reproduce the customizations.
When I saw this question, first I searched for Joel Spolsky's answer. Bit disappointed, so I planned to add it here.
Hope everyone is aware of Joel Test on Careers.
From his blog on The Joel Test: 12 Steps to Better Code
3. Do you make daily builds?
When you're using source control, sometimes one programmer
accidentally checks in something that breaks the build. For example,
they've added a new source file, and everything compiles fine on their
machine, but they forgot to add the source file to the code
repository. So they lock their machine and go home, oblivious and
happy. But nobody else can work, so they have to go home too, unhappy.
Breaking the build is so bad (and so common) that it helps to make
daily builds, to insure that no breakage goes unnoticed. On large
teams, one good way to insure that breakages are fixed right away is
to do the daily build every afternoon at, say, lunchtime. Everyone
does as many checkins as possible before lunch. When they come back,
the build is done. If it worked, great! Everybody checks out the
latest version of the source and goes on working. If the build failed,
you fix it, but everybody can keep on working with the pre-build,
unbroken version of the source.
On the Excel team we had a rule that whoever broke the build, as their
"punishment", was responsible for babysitting the builds until someone
else broke it. This was a good incentive not to break the build, and a
good way to rotate everyone through the build process so that everyone
learned how it worked.
Though I haven't got an opportunity to make daily builds, I'm a great fan of it.
Still not convinced? Check out the brief here in Daily Builds Are Your Friend!!
You don't actually, what you should be wanting is Continuous Integration and automatic testing (which is a step further than nightly builds).
If you are in any doubt you should read this article by Martin Fowler about Continuous Integration.
To summarize, you want to build and test as early and often as possible to spot errors immediately so they can be fixed while what you were trying to achieve when you caused them is still fresh in your mind.
I'd actually recommend to do builds every time you check in. In other words, I'd recommend setting up a Continuous Integration system.
The advantages of such a system and other details can be found in Fowler's article and on the Wikipedia entry among other places.
In my personal experience, it's a matter of Quality Control: every time code (or tests, which can be seen as a form of requirements) are modified, bugs might be creeping in. To ensure quality you should make a fresh build of the product as it would be shipped and perform all the tests available. The more often this is done, the less likely bugs will be allowed to form a colony. Therefore, daily (nightly) or continuous cycles are preferred.
In addition, whether you restrict access o your project to developers or a larger group of users, a nightly build enables everyone to be on the 'latest version', minimizing the pain of merging their own contributions back into the code.
You want to do builds on a regular schedule in order to catch problems with integration of code between developers. The reason you want to do this nightly, as opposed to weekly or on some longer schedule, is that the longer you wait to discover these kinds of problems, the more difficult it will be to resolve them. The practice of doing a build on every check in (Continuous Integration) is just taking the nightly build process to a logical extreme.
The side benefit of having a repeatable build process is important in the long run as well. If you work on a team where there are multiple projects going on, then at some point you will need to be able to easily recreate an old build, perhaps for creating a patch. :(
The more you can automate the build process, the more time you will save for each subsequent build. It also takes the build process itself off of the critical path of delivering the final product, which should make your manager happy. :)
It also depends on the size and structure of the team(s) working on your project. If there are different teams relying on each others API, it may make a lot of sense to have nightly builds for frequent integration. If you're hacking away with only one or two team mates it may or may not be worth it.
Depending on the complexity of your product continuous integration may or may not be able run a full test suite.
Imagine Cisco testing a router with the literally 1000s of different setups to test. To run a full test suite on some products takes time. Sometimes weeks. So you need builds for different purposes. A nightly build can be the basis for a more thorough test suite.
I think they are very important especially on projects with more than 1 person. The team needs to know ASAP if someone:
checks in a bad file
doesn't check in a file
...
Any build automation is better than no build automation :-)
Personally, I prefer daily builds - that way if the build doesn't work then everyone is around to get it fixed.
In fact, if at all possible then Continuous Integration builds are the way to go (i.e. a build on every check-in) as that minimizes the amount of change between a build and so makes it easy to tell who broke the build and also easy to fix the build.
Well ... I guess it depends a lot on your project, of course. If it's just your hobby project, with no releases, no dependencies, and noone but you submitting code, it might be overkill.
If, on the other hand, there's a team of developers all submitting code, automatic nightly builds will help you ensure the quality of the code in the repository. If someone does something that "breaks the build" for all others, it will quickly be noticed. It is possible to break the build without noticing, for instance by forgetting to add a new file to the repository, and nightly builds in a centralized location will detect these quite quickly.
There are of course other possible benefits, I'm sure others will supply them. :)
Nightly builds are only necessary for significantly large projects (when it takes too long to build it often throughout the day). If you have a small project that does not take long to build you can build it as you get functional pieces of code done so that you know that you did not mess anything up in the procees. However, with larger projects this is not possible so it is important to build the project just so that you know that everything is still in working order
There are several reasons, some will be more applicable than others
If your project is being worked on by two or more people
It's a good way to grab the latest version of code that you aren't working on
A nightly build provides a slice in time of the current state of the code
A nightly build will give you a stable build if you need to send code to people
Nightly builds aren't always necessary - I think they're only really useful on big projects. But if you're on a big project, a nightly build is a good way of checking that everything is working - you can run all your tests (unit tests, integration tests), build all your code - in short, verify that nothing is broken in your project.
If you've got a smaller project your build and test times will be shorter so you can probably afford to do more regular builds.
Nightly builds are ideal for performing static code analysis (see qalab and the projects it collects stats from if you are in java world). Unfortunately, this is something that's rarely done.