This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
SpecFlow/BDD for Unit Tests?
Over the last few years I have worked in TDD using NUnit/Moq and over the last few months I have been getting to grips with BDD using mSpec.
So far so good but we now want to move more into acceptance criteria based tests where the business analysts are involved and we get an outside in development process.
So now we have predefined Gherkin syntax files and with specflow it feels the right way to work.
However, at a unit test level having predefined Gherkin files would go against what I understand about TDD. In other words, you design as you go a long evolving your design with behaviour.
As we are working using the outside in approach, now at unit test level could it be that we now have the specifications/behaviors that can now be used to drive my unit tests (just feels like it is against the way I have been doing TDD)?
Earlier these files were important for acceptance tests but as a developer I will work alone so they are not necessary unless I use SpecFlow.
Also what benefit would we have at a unit test level having GWT files maintained when we are using mspec? Developers should be able to just jump into the code and read the tests or just run the test runner to see what it is doing.
TIA
JD
My spontaneous answer is No.
Tha main benefit of BDD and tools like specflow and Cucumber is communication with the stakeholders of the project and creating a shared understanding of what is to be built.
The main benefit of TDD is to take small steps through a solutions implementation, ensuring that you build maintainable and great code.
Or if you want; BDD is about ensuring that we're building the right thing, TDD is about ensuring that we're building it right.
I answered a question like this the other day on my blog, if you want more details; http://www.marcusoft.net/2011/11/bdd-and-technical-scenarios.html
Related
I am trying to optimize the current Automation testing we use for our application. We currently use a combination of Selenium and Cucumber.
Right now the layers we use are:
TEST CASE -> SELENIUM -> Browser.
I have seen recommendations that its better to use TEST CASE -> FRAMEWORK -> SELENIUM -> BROWSER, that way when changes happen in the UI you only need to update the framework and not each test case.
The Question is our scripts are currently broken up into individual steps so when changes to UI happen we only update a script or two, is it better to use this approach with
several scripts that execute for each test case
or go to the framework approach
where the classes, methods, etc. reside in the framework and the test cases just call the methods with parameters for each step?
It depends on:
the life cycle of your testing project, a project with a long life cycle is more worthy to develop a framework for than a short one.
how often you need to update your test cases ( which in turn depends on how often those web pages under test change), a volatile webpage will demand its test scripts to be updated more regularly. Having a framework improves maintainability. (that is, if this framework is well written).
Introduce a framework has the following pros and cons:
pros: easier maintenance, you no longer need to modify your code in multiple test cases, this will save your effort and time. And you get to re-use your framework over and over again for future projects, which will save you time and effort in a long run.
cons: will have development overhead, extra money and effort are required to achieve it. If this project is small and short, the effort and money you spend on introducing a framework may even out-weight its benefits.
We are about to embark on a greenfield development using Go for the API tier and would like to use something like Cucumber or Gherkin to develop the specifications along with non-technical stakeholders.
What are our options here in terms of tooling?
This is really too broad of a question and may get closed.
But... A little Googling is all you have to do:
https://golanglibs.com/top?q=bdd
Disclaimer: my BDD package is 9th on that list:
https://github.com/eduncan911/mspec
It doesn't take much to implement your own BDD workflow.
And now with Go 1.7 on the horizon (beta), there are now SubTests that further allow you to encapsulate BDD style contxt grouping and writing with no "package" needed.
While the refactoring step of test driven development should always involve another full run of tests for the given functionality, what is your approach about preventing possible regressions beyond the functionality itself?
My professional experience makes me want to retest the whole functional module after any code change. Is it what TDD recommends?
Thank you.
While the refactoring step of test driven development should always
involve another full run of tests for the given functionality, what is
your approach about preventing possible regressions beyond the
functionality itself?
When you are working on specific feature it is enough to run tests for the given functionality only. There is no need to do full regression.
My professional experience makes me want to retest the whole
functional module after any code change.
You do not need to do full regression but you can, since Unit tests are small, simple and fast.
Also, there are several tools that are used for "Continuous Testing" in different languages:
in Ruby (e.g Watchr)
in PHP, (e.g. Sismo)
in .NET (e.g. NCrunch)
All these tools are used to run tests automatically on your local machine to get fast feedback.
Only when you are about to finish implementation of the feature it is time to do full run of all your tests.
Running tests on Continuous integration (CI) server is essential. Especially, when you have lots of integration tests.
TDD is just a methodology to write new code or modify old one. Your entire tests base should be ran every time a modification is done to any of the code file (new feature or refactoring). That's how you ensure no regression has taken place. We're talking about automatic testing here (unit-tests, system-tests, acceptance-tests, sometimes performance tests as well)
Continuous integration (CI) will help you achieve that: a CI server (Jenkins, Hudson, TeamCity, CruiseControl...) will have all your tests, and run them automatically when you commit a change to source control. It can also calculate test coverage and indicate where your code is insufficiently tested (note if you do proper TDD, your test coverage should always be 100%).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I've never used CI tools before, but from what I've read, I'm not sure it would provide any benefit to a solo developer that isn't writing code every day.
First - what benefits does CI provide to any project?
Second - who should use CI? Does it benefit all developers?
The basic concept of CI is that you have a system that builds the code and runs automated tests everytime someone makes a commit to the version control system. These tests would include unit and functional tests, or even behavior driven tests.
The benefit is that you know - immediately - when someone has broken the build.
This means either:
A. They committed code that prevents compilation, which would screw any one up
B. They committed code that broke some tests, which either means they introduced a bug that needs to be fixed, or the tests need to be updated to reflect the change in the code.
If you are a solo developer, CI isn't quite as useful if you are in a good habit of running your tests before a commit, which is what you should be doing. That being said, you could develop a bad habit of letting the CI do your tests for you.
As a solo programmer, it mainly comes down to discipline. Using CI is a useful skill to have, but you want to avoid developing any bad habits that wouldn't translate to a team environment.
As other people have noted, CI does have advantages for a solo developer. But the question you have to ask yourself is; is it worth the overhead? If you're like me, it will probably take an hour or two to set up a CI system for a project, just because I'll have to allocate a server, set up all the networking, and install the software. Remember that the CI system will only be saving you a few seconds at a time. For a solo developer, these times aren't likely to add up to more than the time it took to do the CI setup.
However, if you've never set up a CI system before, I recommend doing it just for the sake of learning how to do it. It doesn't take so long that it isn't worth the learning experience.
The benefit of CI lies in the ability to discover early when a check in has broken the build. You can also run your suite of automated tests against the build, as well as run any kind of tools to give you metrics and such.
Obviously, this is very valuable when you have a team of commiters, not all of whom are diligent to check for breaking changes. As a solo developer, it is not quite as valuable. Presumably, you run your unit tests, and even maybe integration tests. However, I have seen a number of occasions where the developer forgets to checkin a file out of a set.
The CI build can also be thought of as your "release" build. The environment should be stable, and unaffected by whatever development gizmo you just add to your machine. It should allow you to always reproduce a build.
This can be valuable if you add a new dependency to your project, and forget to setup the release build environment to take that into account.
If you need to support multiple compilers then it's handy to have a CI build system to do all of that whilst you just develop in one IDE. My code builds with Vc6 through VS2008 in x86 and x64 builds on VS2005 & 8, so that's 7 builds per project per project configuration... Having a CI system means that I can develop in one IDE and let the CI system prove that all of the compilers that I support still build.
Likewise, if you are building libs that are used by multiple projects then CI will make sure they work with ALL of the projects rather than just the one that you're working with right now...
The truth is, that continuous integration makes most sense in teams. Single developers can also get some advantages, you must decide yourself if they are enough to counter the time you invest into setting a CI-system up.
If you forgot to checkin some needed file, the repository contains a broken version, even if it works on your machine. CI would detect that case.
If your CI-server runs on a different machine, it can indicate dependencies on your build-environment. Means, the build and all tests can work on your dev-box, but on another machine some dependencies aren't fulfilled and the build breaks.
Daily builds can indicate, that your older software doesn't work with the newest upgrade of the OS/compiler/library...
If your CI-system has an archive of build-artifacts you can easy get an distribution of an older version of your software.
Some CI have a nice interface to show you metrics about your build, have links to automatic generated documentation and stuff like that.
We use our CI system to do Release builds (as well as the usual automatic "on-commit" builds).
Being able to click a button that kicks off a Release build that steps through all the processes to release a setup is:
fast (I can go straight on with other things, and it runs on a separate machine so it is not slowing me down);
repetitive (it doesn't forget anything, including copying the setup to the release folder and notifying everyone who needs to know)
dependable (no mistakes, unlike a human!).
In an Agile environment, where you expect to be delivering working software every 2-4 weeks, this is definitely worth having, even in a team of 1.
CI benefits a solo developer in the sense that you're aware if you forgot to check something in (because the build will be broken). The integration value of it is diminished when there are no other developers, though.
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 3 years ago.
Improve this question
I'd be leading a new project soon. And I've been pondering over what are the basic infrastructure for a software project. These are the stuff that I think every project should have:
-Coding style conventions
-Naming conventions
-Standard project directory structure(eg maven standard dir layout, etc)
-Project management and issue tracking(eg trac, redmine, etc)
-Continuous Integration server(eg, hudson, cruise control, etc)
I'm not sure if I missed out anything. Would anyone like to add?
As a preliminary answer, check out the Joel test:
http://www.joelonsoftware.com/articles/fog0000000043.html
Just an appetizer:
Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?
revision control system (eg. subversion, cvs, git)
In addition to yours I will put:
Unit Test Strategy
Integration Test Strategy
Defined Process
Release (delivery) strategy (like milestones, working packages and so on)
Source control branching strategy
What about documentation - how (comments in code, high-level specs), when, amount, who
How you will test - unit/acceptance/user testing
code versioning, some SVN/Git (or is it included in trac?)
team roles and responsibilities - need to be done in ocntext of your project
Knowledge management is crucial. As you already plan to use wiki (like Trac or Redmine) you could use it for KM as well.
Functional testing is a mandatory part of any project. Unit testing is great and it works well for Agile projects but the functional testing is still necessary. You need at least a basic Test Plan. If you plan to have multiple projects or sub-projects a Test Strategy document or Wiki page would be good.
Test Cases, Acceptance Test Cases etc could be driven by your User Stories or their equivalents but they still have to exist in some form.
I would throw a file sharing server into the mix too. I thought version control was so basic, that I didn't even bother to put it there in the list. But its a good point version control.
Configuration Management Plan. You need to have a documented approach to your development workstreams, how you will be merging between then, etc.