I have finally started to build a CI server for our project.
during the process, i've examined several build tools and CI servers, such as: CruiseControl\CroiseControl.Net, Ant\nAnt and MSBuild.
these tools have proven themselves enough (just google it..), but one thing similar to all of them was the huge amount of XML configurations that needed to be done in order to get you started.
after a short chat with Nati Dobkin on the subject, he suggested the TeamCity application, this is really a smooth start for the CI, a very modular & user freindly system that allows you to do what you need in the shortest way.

What am i talking about you ask ?
how does the rabit hole got to do with all of this ?

after setting up the environmet, i've started to try get this work with our project.
at first glance, this task should be easy : get the source from TFS, compile, create deployment files, deploy the files.

Q: what do you think will happen if you take your solution to an isolated environment and try to compile it?

A: if project was conducted badly, you'll probably get missing reference errors.
it even get more intresting if those missing Dll's reside in a different workspace(in the TFS), and the only thing that links this project to the other dll's is the physical path ON YOUR HARD DRIVE.
not exactly the right way to go.

Possible solutions:

• preserve the physical link and hold your breath that nothing bad ever happen
• make some order in the TFS server
• create a different solution for each Application\server in the system.

what do you think is the best way to go?
leave a comment.

as we described, The narrative should include a role, a feature and a benefit

“As a [role]
I want [feature]
so that [benefit]”

This template has a number of advantages.
By specifying the role within the narrative, you know who to talk to about the feature.
By specifying the benefit, you cause the story writer to consider why they want a feature.
It gets interesting if you find the feature won’t actually deliver the benefit attributed to it.
This usually means you have a missing story.
if there is one story with the current feature, which delivers a different benefit (and is therefore still useful), then there is a hidden story whereby you will need a different feature to deliver the benefit described.

The scenario title should say what’s different- You should be able to line up the scenarios side by side, and describe how they differ using only the title. It should be obvious from the title whether this is the scenario you care about, compared to the others.

The scenario should be described in terms of Givens, Events and Outcomes
This is the single most powerful behavioral shift in the adopting BDD process.
Simply by getting the business users, the analysts, the testers and the developers to adopt this vocabulary of “given/when/then”, they discover that a world of ambiguity falls away.
Not all scenarios are this simple.
Some are best represented as a sequence of events, described as:

given [some context]
 when [I do something]
then [this happens]
when [I do another thing]
then [this new thing happens]

And so on.

An example is a wizard-style website, where you step through a sequence of screens to build up a complex data model.
It is perfectly appropriate to intermingle sequences of events and outcomes, as long as you get into the habit of thinking in these terms.
One interesting emergent behavior is that the quality of the conversation changes.
You will quickly discover that you have missed out an assumed given, or forgotten to verify an outcome.
By introducing the given/when/then vocabulary, we can dramatically improve the quality of the group interaction.

The givens should define all of, and no more than, the required context:
Any additional givens are distracting, which makes it hard for someone looking at the story for the first time – whether from the technical or business side – to understand what they need to know.
Similarly any missing givens are really assumptions. If you can get a different outcome from the givens provided, then there must be something missing.

The event should describe the feature :
The event itself should be very simple, typically only a single call into the production code. As discussed above, some scenarios are more complicated than this, but mostly the scenarios for a story will revolve around a single event. They will differ only in the context (the givens) and the corresponding expected outcomes.

The story should be small enough to fit in an iteration :
There are no hard and fast rules about how you do this, as long as you break it down into demonstrable chunks.
In general if there are more than about five or six scenarios, a story can probably be broken down by grouping similar scenarios together.
 

When we need to understand what a computer system is supposed to do so that it can best serve some business need, questions like:
• What is the most important thing the system should do?
• What is the next most important thing the system doesn't yet do?
• If we were to switch off the system, where and what would be the biggest impact?

These Powerful questions can be tough to answer.
But following these will guide us to insights that we hadn't though of.

the Acceptance Criteria consist of a collection of Scenario allow us to determine when we are done, The most important aspect of a story is the language in which it is written.
The golden rule is that the Story should be written in the language of the Role, that is to say the beneficiary of the feature.
If the Story represents a business feature, it should be written in business terms with the aid of a business analyst.
If the story describes a technical requirement, such as resilience or scalability (sometimes called “non-functional” requirements), it should be presented in the appropriate technical language.
Acceptance Criteria specify, as a collection of Scenario, what needs to be achieved if the Behavior of the Feature is to be considered finished.

A Scenario:
Some Behavior that can be automatically verified once the Story (or some part of it) is delivered.
The Scenario sets up the world in a known state (or in a way that will behave deterministically) and executes a sequence of one or more Events resulting in one or more verifiable Outcomes.
We commonly implement these scenarios, as FIT fixtures, Selenium tests or programmatically as code, but the technology is less important than the concept here, the aim of these verifiable scenarios is to define what a successful outcome looks like.

This use of Scenarios gives us two immediate returns.

• They form the basis for our estimates, leading to more consistent estimates than story-level estimations.
• They show when a story is trying to do “too much”.
  If there are more than a handful of scenarios (five or six), it suggests that the story should be split into several smaller stories, each providing independent benefit, and each consisting of a subset of the scenarios.
  Boundary or exception cases are good examples of this: sets of boundary scenarios might clump together to describe common business cases, and some of these clusters will be deemed more important than others. Smaller stories means finer-grained control over prioritization, finer grained visibility of progress and reduced exposure to technical risk.

Scenario structure:

Scenario 1: Title
Given [context]
And [some more context]…
When  [event]
Then  [outcome]
And [another outcome]…

the nerrative Gives us a brief description of what to deliver,
and why we should deliver it (in the form of Features and Benefits).

we shall define few terms:

A Role:
Is an aspect that describes the person, or thing, that will benefit from the Feature.
It is essentially the same as an Actor in a UseCase.

A Feature:
It describes something that the system should do (the behavior, as it were).
An important aspect of a Feature is that it is described solely in business terms and not in terms of technology or technologists,
unless of course the business is technology or technologists!!

A Benefit:
This is the reason we are delivering a particular Feature– it describes the business value accrued from this Feature.
Initially the Benefit is usually qualitative,
but we usually expect to see some quantitative business value assigned to the Story before it is chosen for development.
This is to help keep us honest and to ensure that we are focusing our development efforts on Features that have real business value.

To ensure that we don't forget any of these critical components we often use a template for the narrative like this:

As a <Role>
I want <Feature>
So that <Benefit>

A concrete example may be something like:

As a Developer
I want to be able to rename classes
So that I don’t spend too much time worrying about getting the name right first time

The reason for this degree of formality is that it helps us avoid some common analysis anti-patterns.

Two in particular are worth mentioning: 

• Feature = Benefit.
  This is where the “benefit” is simply a restatement of the feature, this is a common failing in technical or semi-technical customers,
  who wish to promote a particular technical solution.
  These requirements can often be (diplomatically) eliminated, reducing complexity, risk and the associated cost.
• Feature ≠> Benefit. (“Feature does not imply benefit”)
  The feature described will not deliver the benefit described.
  When this occurs it often reveals hidden requirements.
  It may be that the Feature delivers a completely different benefit which we hadn't identified.
  Conversely, we may need to introduce some new Feature to actually achieve the specified Benefit,
  a previously hidden, and thus unplanned, feature.

if you haven't read the introduction yet, please read the introduction to BDD

What is this story all about ?
The idea is that the words you use influence the way you think about something.
To smooth its path through the development process, We say that it must fulfill certain additional criteria.

A story should have a Title, a Narrative and AcceptanceCriteria:

Title:

Gives us a label to describe this piece of function throughout the life of the project.
It is important to choose good titles to describe the story,
Since the story is an atom of development and as such is referred to in all sorts of conversations throughout the life of the project.

Poor titles for stories are things like: 
   • Implement Performance Enhancements 
   • Move Data 
   • Create Persistence Layer

Titles should describe the story in business terms, and should make sense when,
For example, considered as a unit of value for the system.

Some examples of better titles may be: 
   • Accept Credit Card Payment 
   • Confirm Exchange Rate 
   • Accept Product Updates

In the last few weeks, i was doing a deep dive into some development methodologies such as TDD, BDD, and scrum.
what was bothering be about the TDD approach is the concept of designing for testability.
in early stages of my research, i spoke with Nati, a good friend of mine that practicing TDD in his team,
he told me that in order to write practice TDD it is imperative to write testable code.
What is testable code i asked ?
Well, this is not a simple question to answer, roy Osherove has even written a book about that,
from changing the design of your application, like using MVP to an "Inherit & Override" practice .
all these practices make your TDD life easier, but we need to ask ourselves one simple question :
"What is the purpose of your application ?",
seems like a stupid question to raise, but due to the noticeable progress of the software industry towards TDD blindly,
this may affect the software performance/Quality "Just" for making our code testable.

I came across Eli Lopian's article about Stop Designing for Testability, which confirms my concerns about the issue, i Totally agree with him.
testable code has an added value, but must we not forget the real purpose of the application, which is to run best in production environment.

This post is a sort of a reply post to nati's post - Testable code, is it worth it ? regarding that matter.

Testable application is certainly an added value to the development process and to the business as one,
but we must be careful not to make it the main issue of the application.
a great example of how TDD should be done is the TypeMock.Net tool, which allows you coding TDD without affecting the performance and OOP design of the application, in my opinion, this is the way to go the TDD way.

What do you think about this matter ?

The last two weeks I'm doing a deep dive into development automation process, which should save allot of time.
a big part of a development process is testing, and as of that many methodologies emerged such as TDD(Test driven development) and so.
The main purpose of these test driven methodologies is to produce a better quality code by creating a set of tests and then write a testable code.

What is BDD?
Behavior-driven development (BDD) is an evolution of test-driven development (TDD) and acceptance-test driven design,
and is intended to make these practices more accessible and intuitive to newcomers and experts alike.
It shifts the vocabulary from being test-based to behavior-based, and positions itself as a design philosophy.

let me explain it in a more explicit way:
as a newcomer to the TDD like process, I found myself asking questions like :
How vastly my tests should me?
Where do I start?
How do i integrate the TDD process with the rest of the development process?
How to write a testable code?
What would be the impact of it?
How do I justify it to the stakeholders?

often stakeholders aren't eager for process changes especially if they are unfamiliar with the new techniques,
cons seems to be having a greater impact on a decision process rather than the major advantages, even if they are insignificant comparing to the advantages.

In what way does the BDD elevate the TDD process?
To answer that question, let's put aside the code writing and the testing process and focus on the entire development process.
Often technical person and a business person speak in "different languages", even analysts and developers sometimes suffer from misunderstandings.
Behavior driven development is a technique that designed to eliminate ambiguity and miscommunication between people on different roles.

this technique comes to solve one basic thing : how do i write a process requirement in a way that would be understandable to all the development personnel, and ensure that the implementation covers the requirements.

To answer the question "where do I start?" ask yourself "what is the next most important thing that the system does not do?"
This question should get you started.

Lets define our requirements in the following template :
As a [role]
I want [Feature]
So that [Benefit].

Defining requirment in this way answers a few important questions:

• Who is the stakeholder for the given request (this is the person that should care about the wanted feature)
• What is the needed functionality?
• What would be the benefit from this specific feature?

Note that when these specific questions answered, you can see which features are more important (and which are not relevant at all).
this way interaction with all the development related personnel will be in "the same language".

Developing scenarios that could happen due to given requirement!
i find the word "scenarios" or even "specifications" more pleasant than "Test" for some reason,
no matter how you look at it, success of these "scenarios", which are situations or a set of rules that must be handled in a specific way, are viable to the success of your project/product/feature development.

Ok, this is all great, but how all this relates to TDD ?
glad you asked this question, i see it in a very simple way:
If the system fulfills all the acceptance criteria, it's behaving correctly.

To summarize all this,
i would say that BDD is a way to produce an idea for a requirement into an implemented, tested production ready code.

stay tuned for the second part about writing scenarios, development tools and more.

I'm sure that if you reading this blog, you have encountered a bug or two (at least).
Now, as you know, often you have to solve bugs of other people that have been fired/left/not available at the moment or just frustrated from it and need a fresh pair of eyes to look at it.

So, you need to deal with the bug, just you and him, like a dual,
What do you do? , how do you confront this mysterious daemon?
 
Most of the people that inherit a bug, clueless regarding his data, try to confront with it straight forward.
Ask a common developer how would he handle a bug, 9 of 10 answers will be "debug".
well, i think it's wrong, it's like knowing that there is a giant brick wall and still running at full speed right in to it.
(unless you are "The Hulk", it won't work)

here is how I'm dealing with a bug :

• Bring it to your own game court - whenever you have a situation, it's always happens in some environment.
  it's crucial to know it as it was your own place.
  suppose you have a .Net Web application running on a windows server 2003, you need to know damn sure all the environment laws regarding it.
  thing like how IIS handle requests or how security configurations should be, are vital to your diagnosis of the problem.
  
• Understand the symptoms right - i have a TV series that i watch , called "House", it's about a brilliant diagnostician doctor that works mostly in unconventional ways and solves the most bizarre cases by doing that.
  i tend to refer this TV series as an educational show on how to handle strange cases and how to approach them.
  on one of it's episodes they had a brilliant dialog:
  - "House, the patients kidneys are shutting down"
  - "Great, we have another symptom"
  
• Write it down - get yourself a notebook or even a giant white-board to write all these symptoms that you have found, it should be right in-front of you all the time until you have solved the case.
  
• Ask yourself What can cause it ? - preferably do this out loud, ask your self that question regarding each symptom that you found, maybe even with a team , that could confirm it or deny your theories.
  
• What was changed ? - this is the most important question that you need to ask yourself.
  things does not go wild on their own,if it worked before and now does not, then something is changed.
  this would be our biggest clue to solve the problem !
  this could be an environmental change, a change in the situation that the application handles or a coding change,
  each one of these can cause a problem, we need to understand which exactly is it.
  
• Develop a theory - this is the fun part, now you have all the data that you need to solve this bug.
  you know how the environment behaves, you have the symptoms to the problem, things that was been changed, and possible causes to our symptoms.
  now you need the sit a few minutes and think what is the reason that fits to all our gathered data.
  
• Blind tests are the devil - most of them will give you nothing and consume much of your precious time, Get a theory that you think that fits the symptoms and then test it, not the other way around.
  
• Develop a solution to the problem - after we have our theory and we tested it, we need to develop a solution that fixes the problem, this is the easy part.

for example, here is a problem that i have encountered almost a year ago:

8007000e System resource exceeded
Microsoft OLE DB Provider for ODBC Drivers error '8007000e'
[Microsoft][ODBC Microsoft Access Driver] System resource exceeded.

lets try to follow these guidelines and solve the problem:

Bring it to your own game court - this is a windows environment that runs an asp web application based on Microsoft access.
Understand the right symptoms - we have a database that denies any further connections due to resource limits.
Write it down - take a moment to look at those symptoms.
Ask yourself what can cause it - it could be an environmental cause, like connection limits are not enough, or coding mistake that suffers from not closing an opened connection.
What was changed ?  - code wasn't changed, all system configurations was not changed, traffic to your site is doubled.
Develop a theory - since the traffic was doubled, the connections are doubled as well, and thus reaching to the connection limit of our application.
why the application does not clearing the connection resources ? - because the code that opens them does not close them, thus the connections piled up and reaching the connection limit way before the recycling process started.
Test it - recycle the connection pool, simulate traffic that won't be in the connections limit(simultaneously), but can be piled up to reach the limit.
Develop a solution to the problem - if you are intrested for this solution , you can check out my post about it