Shai Raiten's Blog : TDD

מפגש קבוצת ALM בנושא אוטומציה ב–Visual Studio 2012

shair — Mon, 20 May 2013 06:06:00 GMT

בשנתיים האחרונות שאני שומע רק על Coded UI ב – Visual Studio אבל יש עוד כ”כ הרבה מעבר, במפגש הקרוב אני אדבר על כל יכולות האוטומציה ב – Visual Studio 2012 עבור מפתחים ואנשי אוטומציה.

נדבר על Unit Test ויכולת ה – Fakes החדשה שמגיעה עם Visual Studio 2012 (מחליף את Pex & Moles)
ממשק Web Test Manager שמגיע עם Update 2, אשר מאפשר עבודה עם בדיקות ללא MTM.
חידושים ודרכים יעילות לכתיבת Coded UI ועבודה עם דפדפנים שונים כגון FireFox ו – Chrome.
Web Performance Test
Load Testing

בנוסף לא כדאי להפסיד הרצאה של ליאור פרידמן שידבר על ניהול פרוייקטי Agile.

פרטים נוספים ורישום בלינק זה:

http://www.eventbrite.com/event/6729031715

אשמח לראותכם במפגש!

VS/TFS 2012 Update 2 & Update 3 CTP

shair — Wed, 08 May 2013 06:55:20 GMT

Couple of days ago Brian Harry post about the new release of Update 2 for Visual Studio and TFS 2012, and today another release of Update 3 that isn’t big a Update 1 and 2 but contains a set of bug fixes that can ease you work.

Before jumping to Update 3, if for some reason you’re not using Update 2 this is the time to read about it and install it!

Update 2

Update 3 – CTP

Visual Studio 2012.3 (Update 3) “go-live” CTP is now available

Installing it should be relatively straight forward – for both VS and TFS, just run the installer. There should be no compatibility breaks so you need not upgrade all of your components at once, though, over time, you should plan to get them all updated

List Of Improvements – Full List

Technology improvements - Team Foundation Server

Build settings can be preserved when you upgrade a TFS 2012 instance.
Improvements are made in the New Build Definition UI for the Continuous Integration (CI) build in Git-based team projects.

Visual Studio Test

Web test

Microsoft Visual Studio 2010 crashes when you create a Web test on a computer that has both Visual Studio 2010 Service Pack 1 (SP1) and Visual Studio 2012 Update 2 installed.

Coded UI test

You cannot run coded UI together with the cross browser testing feature by using Selenium components.

Load test

When you analyze a load test run, parts of the results are missing from the graph in the default view

Unit test

783438: Mstest.exe fails to execute unit because of missing assemblies

Administration and Operations

The event log does not include stack traces when the administrator console crashes.
You cannot configure TFS proxy on a computer that belongs to a separate domain from a TFS 2012 server.
TFS 2012 backup plan wizard does not report an error when you configure a backup plan by using the Local System account.
A user who does not have read permission on an area path can receive email notifications of changes to work items under the area path.
Slow performance when you open a work item that has many customized fields in TFS Web Access.
Fix adds upload retries for Version Control files that are being checked in or shelved to reduce the number of deceptive errors.
More

Enjoy

A-s-shole Driven Development

shair — Mon, 14 Feb 2011 16:15:22 GMT

A-s-shole Driven Development

Yes I know this sound interesting and yes it is!

Yaniv Kessler has sent my that email and I felt that I need to share this knowledge with you!

Scott Berkun wrote a very nice article of what he think is the reason for all those acronyms and frameworks keep piling up in the software industry.

*** Driven development (ADD) – Any team where the biggest jerk makes all the big decisions is *** driven development. All wisdom, logic or process goes out the window when Mr. *** is in the room, doing whatever idiotic, selfish thing he thinks is best. There may rules and processes, but Mr. A breaks them and people follow anyway.

Read the Full Article

Run Unit Tests in Parallel using Visual Studio 2010

shair — Thu, 30 Dec 2010 23:12:33 GMT

Run Unit Tests in Parallel using Visual Studio 2010

Today almost each and every machine have multiple CPU’s or a CPU with multiple cores, so why not using them in order to speed up your tests runs and run more Tests in parallel.

In Visual Studio 2010 Microsoft added the ability to run Tests (Only for Unit Tests) in parallel.

Data Collectors cannot be enabled if using Parallel execution.
You must have multi-core/CPU machine

How To Enable Parallel Execution of Unit Tests

1. Create new Test Project in Visual Studio 2010

2. Right click on “Local.testsettings” and click “Open With”, choose “Xml (Text) Editor” and hit OK.

3. Expand the Execution Tag and add additional attribute called – parallelTestCount:

What’s are your options:

0 = Auto configure: We will use as many tests as we can based on your CPU and core count
Define the number of tests to run in parallel – If you don’t want to use all cores/cpu’s

This is my code for that Demo:

As you can see from the picture below I have 4 unit tests running in parallel and another picture below you can see my computer finally working

Enjoy

Behavior Driven Development

Shai Raiten — Mon, 05 May 2008 20:04:46 GMT

Behavior Driven Development

Behavior Driven Development (or BDD) is an Agile software development technique that encourages collaboration between developers, QAs and non-technical or business participants in a software project. It was originally conceived in 2003 by Dan North as a response to Test Driven Development, and has evolved over the last few years.

The focus of BDD is the language and interactions used in the process of software development. Behavior-driven developers use their native language in combination with the ubiquitous language of Domain Driven Design to describe the purpose and benefit of their code. This allows the developers to focus on why the code should be created, rather than the technical details, and minimizes translation between the technical language in which the code is written and the domain language spoken by the business, users, stakeholders, project management etc.

BDD Practices

The practices of BDD include:

Driving development from the outside-in
Using examples to describe the behavior of the application, or of units of code
Automating those examples to provide quick feedback and regression testing
Using 'should' to help drive out responsibility and allow the behavior to be questioned
Using 'ensure' to differentiate between outcomes which are the responsibility of the code in question, and those caused by other elements of code as a side-effect
Using mocks to stand-in for modules of code which have not yet been written

Outside-In

BDD is driven by Business Value; that is, the benefit to the business which accrues once the application is in production. The only way in which this benefit can be realized is through the User Interface(s) to the application, usually (but not always) a GUI.

In the same way, each piece of code, starting with the UI, can be considered a stakeholder of the other modules of code which it uses. Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.

The first piece of production code that BDD developers implement is the UI. Developers can then benefit from quick feedback as to whether the UI looks and behaves appropriately. Through code, and using principles of good design and refactoring, developers discover collaborators of the UI, and of every unit of code thereafter. This helps them adhere to the principle of YAGNI, since each piece of production code is required either by the business, or by another piece of code already written.

Scenarios, or Application Examples

The requirements of a retail application might be, "Refunded or replaced items should be returned to stock."

In BDD, a developer or QA might clarify the requirements by breaking this down into specific examples, eg.

Scenario 1: Refunded items should be returned to stock

Given a customer buys a black jumper
and I have three black jumpers left in stock
when he returns the jumper for a refund
then I should have four black jumpers in stock

Scenario 2: Replaced items should be returned to stock

Given a customer buys a blue jumper
and I have two blue jumpers in stock
and three black jumpers in stock
when he returns the jumper for a replacement in black
then I should have three blue jumpers in stock
and two black jumpers in stock

Each scenario is an exemplar, designed to illustrate a specific aspect of behavior of the application.

When discussing the scenarios, participants question whether the outcomes described always result from those events occurring in the given context. This can help to uncover further scenarios which clarify the requirements. For instance, a domain expert noticing that refunded items are not always returned to stock might reword the requirements as "Refunded or replaced items should be returned to stock unless faulty."

This in turn helps participants to pin down the scope of requirements, which leads to better estimates of how long those requirements will take to implement.

The words Given, When and Then are often used to help drive out the scenarios, but are not mandated.

These scenarios can also be automated, if an appropriate tool exists to allow automation at the UI level. If no such tool exists then it may be possible to automate at the next level in, ie: if an Model-view-controller design pattern has been used, the level of the Controller.

Unit-level Examples and Behavior

The same principles of examples, using contexts, events and outcomes can be used to drive development at a unit level. For instance, the following examples describe an aspect of behavior of a list:

Example 1: New lists are empty

Given a new list
Then the list should be empty.

Example 2: Lists with things in them are not empty.

Given a new list
When we add an object
Then the list should not be empty.

Both these examples are required to describe the behavior of the

list.isEmpty()

method, and to derive the benefit of the method. These examples can be automated using TDD frameworks. In BDD these examples are usually encapsulated in a single test method, with the name of the method being a complete description of the behavior.

For instance, using Java and JUnit 4, the above examples might become:

public class ListTest {
 
   @Test
   public void shouldKnowWhetherItIsEmpty() {
      List list1 = new List();
      assertTrue(list1.isEmpty());
 
      List list2 = new List();
      list2.add(new Object());
      assertFalse(list2.isEmpty());
   }
}

Sometimes the difference between the context, events and outcomes may be made more explicit. For instance:

public class WindowControlBehavior {
 
    @Test
    public void shouldCloseWindows() {
 
        // Given
        WindowControl control = new WindowControl("My AFrame");
        AFrame frame = new AFrame();
 
        // When
        control.closeWindow();
 
        // Then
        ensureThat(!frame.isShowing());       
    }
}

However the example is phrased, the effect should be that of describing the behavior of the code in question. For instance, from the examples above one can derive:

List should know when it is empty
WindowControl should close windows

The description is useful if the test fails, and provides documentation of the code's behavior to anyone interested in Lists or WindowControls. Once the examples have been written they are then run and the code implemented to make them work in the same way as TDD.

Using Mocks

Because of the outside-in nature of BDD, developers will often find themselves trying to use units of code which don't yet exist. When this happens, an object which is simpler than the desired code, and provides the same interface but predictable behavior, can be injected into the code which needs it.

These objects can either be created by hand, or created using a mocking framework such as JMock or EasyMock.

BDD proponents claim that the use of "should" and "ensureThat" in BDD examples encourages developers to question whether the responsibilities they're assigning to their classes are appropriate, or whether they can be delegated or moved to another class entirely. Questioning responsibilities in this way, and using mocks to fulfill the required roles of collaborating classes, encourages the use of Role-based Interfaces. It also helps to keep the classes small and loosely coupled.