I am working on an article about software testing as a profession. This is a controversial topic to some people and I would like to get your thoughts.

I have created a very short (10-question) survey that will help me write this article. It will only allow 50 respondents, but I would like to invite anyone to participate at:

http://freeonlinesurveys.com/s.asp?sid=uqcp94gonac9cy9267091
I will share the results and also let you know when the article is out.

Thanks for your help!

Randy

There are few topics hotter these days than Mobile Software Development. It seems like every company is rushing to release their own Mobile Application. But when it comes time to build that software they quickly learn that things are different. Many developers claim that it is very difficult to test drive the application and some [...]

While at the msswit conference in the Ukraine, I got to speak on two subjects with the following videos:

• Beautiful Builds:  Maintainable, Coherent Build Processes
• A Second Look at Unit Testing: what I learned since the first edtion of Art Of Unit Testing

Red Gate is looking for feedback on its ASP.NET Web Development Education website.

Visit their website and answer the survey.

Not picking on an API in particular, but…wait, yes I am. Octopus (an awesome product) has a proposed API on GitHub, and one of the things it describes is how to deal with the fact that the backend is built on top of Raven DB, where eventual consistency its default mode for index results.

In it, the proposal includes an “IsStale” flag on the collection, as well as on the query itself, so you could do something like:

GET /api/environments?nonstale=true

Or similar. This presents a rather weird choice to the end user of the API – consistency as a choice, not on mutating operations (PUT/POST/DELETE) but on idempotent GET operations. I presume that this will use the “WaitForNonStaleResults” behavior of RavenDB – but this isn’t really something I’d expect to directly expose to clients.

Without directly exposing our persistence mechanism to our clients (i.e., what if we switched to SQL Server? Redis as a write-through cache to MondoDB? and so on), we have a number of options of dealing with eventual consistency in our REST APIs.

Option 1: Do nothing

The easiest approach for our API is to simply not care. Non-stale results should only really appear when we’re dealing with queries and collections – if you’re dealing with stale resources from GET actions directly against a resource, you’ve really got a weird interaction model.

Looking at some other APIs, like Netflix or GitHub or Trello, you don’t really see any option for influencing the consistency choice on a read.

So we could just ignore it. This is what a lot of APIs do, accept the POST/PUT/DELETE, and make sure that my resource itself is affected correctly. If I do a DELETE /users/jbogard and then a GET /users/jbogard, I expect a 404. But if I query users or search them, then I might not expect those results to be reflected in that model. I can be explicit in this by having search be a completely separate set of resources/entry point (i.e. /search?entity=users&name=jbogard), so it’s completely explicit that search/query is different than interacting with resources.

This is similar to how a library with a card catalog might work. Do I synchronize the activity of checking out a book with checking the catalog? Or might someone have grabbed the book from when I checked the card catalog? Or do I have someone hold the card while checking out a book?

What I don’t do is allow a person looking for a book to either be disappointed OR have the choice of yelling out to everyone in the library, “DOES ANYONE HAVE THIS BOOK OR IS OTHERWISE WANTING TO CHECK THIS BOOK OUT”. I fix my interaction model and just be up front about it.

Option 2: Provide feedback on consistency results

Instead of just punting on whether or not the collection/query is stale, we might provide that as feedback. We could return dates of last update, things like “results as of mm/dd/yyyy”. We often do this on printable reports so that when people print a report (and it is now preeeeeetty much as stale as it gets), we can include a timestamp of when it was printed so that anyone looking at it is informed of how fresh the data is.

Just a tidbit of information to the end user to let them know if their results are up to date or not. If the client made a mutating operation, they can compare the date of this mutation with the date on the query results to make a simple decision to query again, or just move on as planned. Again, the power is in the client not to affect how we query, but what decisions they can make.

Option 3: Return a 202 ACCEPTED status

If we really want to model an asynchronous operation in our REST API, we can look to the HTTP status codes to communicate this explicitly to our clients. We do this in a couple of places where processing is too expensive in the context of a request, so we return a 202 to let clients know that “we got your request, but it’s not getting processed at this moment.” The description from the W3C reads:

The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.

The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent’s connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request’s current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.

We can return a pointer to an indication of the current status, or some estimate of completion. But we’re being 100% up front that your request is processed asynchronously.

This is similar to any long-running transaction. You place an order at a fast-food restaurant, and are given a correlation identifier that represents your order. You can come back and ask the status of your order at any time. But the cashier certainly doesn’t cook our order while we’re standing in line!
Option 4: Write-through cache

If these operations are expected to succeed (or we verify that the transactional write has succeeded), we can do a simple trick that a lot of high-volume websites do. If we don’t have an AP-system like Dynamo (choosing availability and partitionability over consistency), we might choose consistency instead. To do so, we can cache index results, and write our updated value to that store along with our regular persistent store.

It’s not the most exciting of options, but if we know that writes are much less frequent than reads (and we’re not partitioning, i.e. we pick CA of CAP), then it’s not too far-fetched to write to both our cache and our document store.

Of course, if this is all to force us to bypass our consistency model of the database we’ve chosen, it’s a lot of work. But still, it’s an option nonetheless.

Option 5: Choose a database that matches our consistency needs

If we don’t like the consistency model that our database provides, or we feel like we want to allow clients to choose a consistency model, we might view this as a case where we’ve simply chosen the wrong model. If clients NEED consistency, why not pick something that gives that to them? Or don’t allow them to choose.

This would be like, on writes, allowing clients that interact with a database that uses a relational model to also indicate the isolation level on writes. That’s something that should really be encapsulated by the operation, and made with SLAs and contracts about the behavior.

Conclusion

We have a lot of options here, and all are valid in some scenarios. In each example, we’ve chosen a consistency model that matches our needs, rather than have a compromised consistency model exposed from our database of choice. Before Amazon put out their Dynamo paper, it’s not like us as users of the website knew that this storage system existed in the back end. It was encapsulated. The most we could do was “Ctrl+F5” to force a request back to their servers, but that still had no real guarantees.

Instead of letting our database leak its consistency model to our API, it’s better to choose a model that makes this consistency model explicit, or offer no guarantees at all. But as a rule, I as a consumer should not care that you’ve chosen Raven DB instead of SQL Server for your back end. It’s just none of my business.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

My build was failing due to moving to a new build machine. We do have custom packages that are used internally and they could not be found by NuGet on the new server.

This post might be more about me remembering where it is but the location of the package sources for NuGet is found here:

%APPDATA%\NuGet\NuGet.Config

Here is what mine looks like:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageRestore>
    <add key="enabled" value="True" />
  </packageRestore>
  <packageSources>
    <add key="NuGet official package source" value="https://nuget.org/api/v2/" />
    <add key="LocalFeed" value="C:\LocalPackages\" />
    <add key="MyCompany" value="\\myServer\NugetPackages" />
  </packageSources>
  <disabledPackageSources />
  <activePackageSource>
    <add key="NuGet official package source" value="https://nuget.org/api/v2/" />
  </activePackageSource>
</configuration>

The same file can be found on the build server (with some options missing). The main part is the packageSources section.

If you are depending on a local repository or a different repository than the public NuGet Gallery, it’s where you need to update your sources to have your package available.

Posts in this series:

• Observer pattern
• Controller pattern
• Pattern variations
• Scaling sagas
• Routing slips

NServiceBus sagas are a simple yet flexible tool to achieve a variety of end goals. Whether it’s orchestration, choreography, business activity monitoring, or just other long-running business transaction variants, the uses of an NServiceBus saga are pretty much endless.

When choosing to go with a centralized workflow, we also saw that there is a cost to centralization with the introduction of a bottleneck. With the routing slip pattern, we can include instructions with our message in a header so that each recipient only needs to reference the attached instructions. In a routing slip, flow is linear, but there’s nothing stopping us from including more advanced instructions for state machines, compensations and so on.

I tend to think of the NServiceBus saga as more of a facility, than a specific pattern, because it doesn’t force us to go in any one direction. Rather than assume a specific role or function for a saga, I like to keep things a bit more flexible, and choose one of the many conversation/messaging patterns available for each given scenario.

In the end, sagas are a useful tool (and one that can be over-used, not every workflow deserves central management), but a nice one to have. Every time I introduce NServiceBus sagas to folks that spent time with other messaging tools, whether it’s big orchestration with ESBs or bare-metal messaging tools, the simplicity and code-centric nature of NServiceBus sagas either excites or depresses, depending on the possibility of switching or introducing new tools.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

My blogging break has been so long, I feel like a vampire emerging from the grave in a Hammer Horror film. I’m interrupting my relentless working day to announce that I’ll be at: ASWEC...

Visit The Build Doctor for the full article.

This video discusses the differences between the Agile and traditional software development life cycle. It then presents what are the implications of Agile on the software testing activity. Watch this video on http://video.esri.com/watch/2402/software-testing-in-an-agile-world

KnockoutJS is an MVVM JavaScript framework for your browser. It allows you to easily bind raw data to a model and update elements bound to that model.

jQuery is a DOM manipulation framework that has made JavaScript not suck.

Both have their reason to exist and they should actually not compete. It’s all about using the right tool for the right job.

The problem

When building rich HTML page with a lot of input/tag manipulation, the most common manipulation is changing what is displayed. Be it the content of a text box or the content of a tag, we need to update those elements a lot. What we often end up is a lot of jQuery code that selects element and then updates it.

It becomes very quickly clear that increasing the amount of code would make it look like spaghetti code. Another big disadvantage of having all of your UI driven by jQuery is that you end up with a lot of selectors. Unless you are selecting by ID, tag or classes (and depending on your browser), selectors will eventually slow your browser.

So how do we fix spaghetti event binding and keep our head cool?

Fixing the problem with KnockoutJS

Let’s start with some basic HTML:

<div id="myModel">    
    <label>Firstname</label>
    <input type="text" id="firstname" />

    <label>Lastname</label>
    <input type="text" id="lastname" />

    <span><strong id="fullname">Displaying full name here</strong></span>
</div>

That’s the most simplistic example. We have a first name and a last name and we want to concatenate both of them into an tag to display the user and that, in real time. This might seem like an easy problem but keep in mind that real-life problems will actually be more fierce. With that said, let’s start coding.

What would that look like in jQuery?

$(document).ready(function () {
    $("#firstname").on('keyup', UpdateFullname);
    $("#lastname").on('keyup', UpdateFullname);
});

function UpdateFullname() {
    $("#fullname").text($("#firstname").val() + ' ' + $("#lastname").val());
}

We basically have no less than 5 selectors. All based on IDs so they are going to be fast but still… it’s five selectors. We could probably optimize things a bit but this is as close as production code I’ve seen in the wild. The trick for the real-time requirement in this scenario is the ‘keyup’ event. As we add more elements to our model we might have to add more event binding to invoke that function on other elements. Maybe other functions will require that same function too and you end-up with a flurry of selectors left and right with a big JavaScript file of 800 lines of code in no times.

What about KnockoutJS?

$(document).ready(function () {
    ko.applyBindings(new FullnameViewModel(), $("#myModel")[0]);
});

function FullnameViewModel() {
    var self = this;
    self.firstName = ko.observable('');
    self.lastName = ko.observable('');

    self.fullname = ko.computed(function() {
        return self.firstName() + ' ' + self.lastName();
    });
}

Of course, for the KnockoutJS version to work properly, I have to change the HTML a little bit. I’ll also take the time to remove unused attributes (required by jQuery in this case) to work. Here is how it looks now.

<div id="myModel">    
    <label>Firstname</label>
    <input type="text" data-bind="value: firstName, valueUpdate: 'afterkeydown'" />

    <label>Lastname</label>
    <input type="text" data-bind="value: lastName, valueUpdate: 'afterkeydown'" />

    <span><strong data-bind="text: fullname">Displaying full name here</strong></span>
</div>

So what can we understand from that? Yes, it takes a bit more JavaScript to do the work but now, the whole “business rules” are actually encapsulated in one JavaScript function. If we need to reuse part of how the full name is built, it’s actually part of your model. It’s something you can write tests for. As more rules are added to the view model, less time is spent debugging which selector I am to use and more about writing business rules of our presentation layer.

Why should I go with Knockout?

• If your application actually has some business rules that need encapsulating, Knockout will provide you an easy way to do it.
• If you are unit testing your JavaScript, it is much faster and easier to test only the ViewModel without any actual HTML in the back. You could potentially run something like PhantomJS to test your ViewModels.
• If you are going to reuse part of the model in other bits of HTML or simply if your HTML is still changing a lot
• If you need to be able to serialize your whole model in JSON to send to the server.

What should I still use jQuery for?

• Basic DOM manipulation/selection
• Ajax requests
• Effects and animation

Give KnockoutJS a try!

Try it out by going first to KnockoutJS.com and doing the live tutorial. It will be easy to get your feet wet. Then, use it in Visual Studio since it’s part of the template!

By Andrew Trenk
This article was adapted from a Google Testing on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office.

There are typically two ways a unit test can verify that the code under test is working properly: by testing state or by testing interactions. What’s the difference between these?

Testing state means you're verifying that the code under test returns the right results.

public void testSortNumbers() {
  NumberSorter numberSorter = new NumberSorter(quicksort, bubbleSort);
  // Verify that the returned list is sorted. It doesn't matter which sorting
  // algorithm is used, as long as the right result is returned.
  assertEquals(
      new ArrayList(1, 2, 3),
      numberSorter.sortNumbers(new ArrayList(3, 1, 2)));
}

Testing interactions means you're verifying that the code under test calls certain methods properly.

public void testSortNumbers_quicksortIsUsed() {
  // Pass in mocks to the class and call the method under test.
  NumberSorter numberSorter = new NumberSorter(mockQuicksort, mockBubbleSort);
  numberSorter.sortNumbers(new ArrayList(3, 1, 2));
  // Verify that numberSorter.sortNumbers() used quicksort. The test should
  // fail if mockQuicksort.sort() is never called or if it's called with the
  // wrong arguments (e.g. if mockBubbleSort is used to sort the numbers).
  verify(mockQuicksort).sort(new ArrayList(3, 1, 2));
}

The second test may result in good code coverage, but it doesn't tell you whether sorting works properly, only that quicksort.sort() was called. Just because a test that uses interactions is passing doesn't mean the code is working properly. This is why in most cases, you want to test state, not interactions.
In general, interactions should be tested when correctness doesn't just depend on what the code's output is, but also how the output is determined. In the above example, you would only want to test interactions in addition to testing state if it's important that quicksort is used (e.g. the method would run too slowly with a different sorting algorithm), otherwise the test using interactions is unnecessary.

What are some other examples of cases where you want to test interactions?
- The code under test calls a method where differences in the number or order of calls would cause undesired behavior, such as side effects (e.g. you only want one email to be sent), latency (e.g. you only want a certain number of disk reads to occur) or multithreading issues (e.g. your code will deadlock if it calls some methods in the wrong order). Testing interactions ensures that your tests will fail if these methods aren't called properly.
- You're testing a UI where the rendering details of the UI are abstracted away from the UI logic (e.g. using MVC or MVP). In tests for your controller/presenter, you only care that a certain method of the view was called, not what was actually rendered, so you can test interactions with the view. Similarly, when testing the view, you can test interactions with the controller/presenter.

You’ve probably all seen the Publish Method called “Web Deploy” in your Visual Studio 2010/2012 publish popup. On my end, I’ve used the classic “push to a local folder then copy/paste” method of deploying.

Today, I’m going to show you how to install it on your IIS and make it work with Visual Studio

Installing Web Deploy

The first thing to do is downloading the IIS extension and executing it. It should open the Web Platform Installer and suggest you the right version of Web Deploy and then click Install.

Then we need to go to IIS to confirm that it is properly installed. Right clicking on a Site should bring you this menu:

Deploying through Visual Studio

IMPORTANT

You need to run Visual Studio as an Administrator for this to work.

Now when you try to publish an application through Visual Studio, select “Web Deploy” from the drop down and type in your URL.

Visual Studio 2010:

Visual Studio 2012:

In Visual Studio, you could always use the option called Build Deployment Package so that if you have to give a package to your sysadmin (or a client) to deploy, it can be done with single Zip and an package to import. Included in this package can be, folder authorization, registry keys that are required and more.

Why should I use Web Deploy?

• You are not required to be an administrator on the server to publish an application.
• Allow for partial differential deployment (only what changed)
• You can push the database with Entity Framework and run migrations on the different databases
• Synchronize web servers between themselves (IIS6/IIS7/IIS8)
• Easily give a package for a client to deploy
• Easily deploy from a Build server (Continuous integration)
• Automatically backup before publishing

Conclusion

Web Deploy is already in V3 and barely been talked about in our spheres. Maybe we are too development oriented and are not looking at making our tasks easier. In any case, installing the web deploy extension on an IIS server should only take you a few minutes and will be worth it very fast by making your deployments easier than ever.

For more information, do not miss the MSDeploy blog. Or the initial blog post by Scott Guthrie… over two and a half years ago.

Today I read an article on various approaches for Product Backlog Grooming meetings. Underlying the write-up there seemed to be some misconceptions about the purpose and goals, the duration, the participants, the approach, and how often and when to hold a Product Backlog Grooming meeting.

Purpose and goals

The Agile Atlas Core Scrum part mentions the Product Backlog Refinement activity. It’s not necessarily a meeting, but up to 10% of the Development Team’s Sprint time might be used on refining the backlog.

The main purpose of refining the backlog lies in rebuilding the product backlog so that adheres to the DEEP criteria: detailed appropriately, estimated, emergent, and properly ordered (originally: prioritized, but I threw in a deliberate renaming based on recent changes in the Scrum guide).

Detailed appropriately means that we have some product backlog items very detailed. These should be at the top of the current ordering, and they surely will be implemented during the next one or two sprints by the team. On the other hand we have some vague ideas about the product in the future. Some folks call these epics, like large user stories, some call the themes. What really matters is that these are too large, too undetailed to fit into one of the next sprints. We surely have to work on them, refine them, before the team will be able to forecast them in a sprint.

In between there is a large variety of details in the product backlog items. Some are very high-level, others are close to being appropriately for the next sprint.

As part of the backlog refinement activity we have to work with the product backlog to be able to fill at least the next sprint with it. That usually means that we would like to detail enough stories for the next three sprints at most. Detailing more would mean to invest much more effort into unsure work in the future – that could be waste, especially when priorities change based on feedback from the market and customers. Preparing fewer items than for the next sprint accompanies the risk that the team at the next sprint planning will be able merely to plan two stories, where five would fit in. Most teams I have seen do well with having a constant pipeline of one to two sprints worth of backlog items “sprintable” in their backlog.

The backlog also should be estimated. That means we need to do estimation on those items we worked on. These two things together, detailing items, and estimating them, is usually what teams do when they speak about the Backlog Grooming meeting. The emergent and ordering parts – not so much.

That said, the main purpose for the Backlog Grooming meeting lies in preparing enough Product Backlog Items for the next Sprint. Depending on your Product Owner’s rendevouz demand with other folks, you may also need to work on some larger stories, estimate them, and prepare them so that the scope for the current release can be communicated.

Duration and frequency

Time-boxing is a way to foster hard-to-make, critical decisions. In Scrum all meetings are time-boxed. That should also yield for the Backlog Grooming meeting.

Given the Development Team can help the Product Owner on the Product Backlog Refinement up to 10% of their time, that means we could schedule a one day long Backlog Grooming meeting with the whole team on a two week sprint length. I wouldn’t do that. It not only would mean that the team cannot work with the Product Backlog during the rest of the sprint. It would also mean that the team is pulled out of their current sprint for a full day.

What I have seen working for most teams is a weekly one hour Backlog Grooming meeting. When the Sprint starts on a Wednesday, for example, I would schedule the grooming meeting for Mondays. As a Coach or ScrumMaster I would also help the Product Owner to prepare the stories for the grooming meeting, and if there is not sufficient input for a full grooming meeting, I would either cancel the meeting, or make it shorter.

The frequency with some offset to the review, retrospective, and planning meetings helps to make sure you can still clarify open questions for the highest priority items before the planning meeting. Otherwise you would have to leave out an unclear item from the current sprint, even though it has the highest priority right now. That’s usually not a desire.

With one hour each week you also help the Development to focus on their current work most of the time. Your mileage might vary, indeed, but I would be worried if you have to use more than two hours every week on grooming your Product Backlog. That either means that the knowledge gap between the business side and your Development Team is too large, or you have too many uncertainties in your current backlog. Oh, of course, it might also mean that you are deeply into team building, and people try to distract with their hidden agendas during this meeting. Regarding the knowledge gap, you should try training some of the team members in the business domain, either on-the-job with end users and domain experts, or merely send them on a course. Regarding the uncertainties, that might mean that you need to bring a subject matter expert on your team to help them, or you need to invest more effort before being able to have an item in a sprint. These issues usually shouldn’t be solved with more grooming, a longer meeting, etc. The grooming demand instead makes you aware of a potential problem that you should tackle differently.

Participants

At least you need someone with a business domain background, one with knowledge about technical limitations, and one who can challenge the thoughts in the room for completeness, or validity. At least this includes the role of the Product Owner, a programer, and a tester. Some teams do well with just these three experts on their team. Other teams find it more useful to include everyone available in it. I usually start with the latter approach, and lower down the number participants when necessary.

Approach

With the purpose mentioned above, the Product Owner takes the first product backlog item that needs to be either estimated or become more detailed, and the team explores ways to do that. Ellen Gottesdiener and Mary Gorman’s Discover to Deliver provide some more details on this. For the estimation part things like planning poker, bucket estimation, or blink estimation come to mind.

For the detailing part, usually that means to break down backlog items by using one of the splitting cheat sheets available, or exploring ways to break a larger item down into several smaller ones by simply talking. Nonetheless you should be aware of strategies like Dimensional Planning for this as well…

The key thing here is that you should not talk through the whole Product Backlog in one hour every week. That will be dragging for everyone involved. Instead, focus on the most immediate priority. That usually is to be able to fill a sprint from the current Product Backlog. With the time-boxing to one or two hours, you might end up being partly through the backlog, and that’s absolutely ok. In the next week you will be getting deeper into with the next stuff.

I’ve had a love-hate relationship with two-phased commits during my years with messaging. Even if MSDTC was free to set up, it doesn’t come free in terms of throughput. Most people run into 2PC in messaging because because queueing systems and databases are two different resources, and therefore don’t participate in the same transaction. Ideally, I’d have all three participants either succeed or fail together:

Since the queues in this picture are different resources than the database, I need to involve a third party, or transaction manager, to coordinate transactions between these three resources.

DTC, when it works, works really well. It’s much, much easier to not care about the consequences of a lack of coordination. In fact, I’d recommend not caring until you actually do care, because ditching two-phased commits does require work. Luckily for us, there are a ton of resources on how to do exactly that!

Most of the time, literature around avoiding 2PC is concerned about an entirely different situation, where I have two separate databases:

We’re doing messaging, which means that it’s typically the consumer of the message that does something against other data stores. So even though we’re avoiding communicating with two databases, it’s still two resources, and thus a need to coordinate!

But again, that coordination comes with a cost. A fairly large cost, in some recent testing we found that overall throughput dropped 80%, or to put it another way, ditching DTC saw a 5X increase in throughput. Five fold!

For some systems, that throughput doesn’t matter much, but for those that have a reasonably high volume of messages, or sensitive SLAs, it’s worth investigating alternative approaches.

General rules of thumb

Like most messaging approaches, the ways of avoiding coordination are right in front of our faces. In Gregor Hohpe’s excellent paper on Starbucks, he points out any real-world system that values throughput over absolute consistency avoids distributed transactions. The basic ideas are:

• Idempotency is king. Get this and you’re halfway home
• Strategies for dealing with downstream effects is a business decision

Idempotency is absolutely required, but it’s not that hard to apply. For some operations, we can rely on natural idempotency. If I’m asked to turn on the light, receiving the request twice means the same outcome – the light is on! For state machine-like systems, idempotency is a bit easier.

For operations that aren’t naturally idempotent (launch the nuclear missile), we’ll need to get a little creative. If we can identify some correlating information from a request (The president called at 9:15 to launch the missile) or just assign some correlation information (The president has issued request #132 to launch the missile), we can simply keep a journal on the receiving side. If it’s expensive to keep a journal around, we can recycle/trim our journals if they get too big.

Downstream effects become more interesting. If throughput is a high concern, we can rely on compensating actions (customer didn’t have enough money, cancel the order) or more journaling. Instead of sending a message immediately, shouting out messages to downstream systems, we can instead just write down in the same persistent store as our other data another journal for outgoing messages.

Once our local DB transaction is complete, it’s just a matter of sending the messages we’ve written down to send out down the line, and crossing them off our list of “sent” messages. And since downstream systems can deal with at-least-once messages through our idempotency guarantees.

How I learned to stop worrying and ditch 2PC

In some current systems, we’re deciding on a service-by-service basis whether or not we want to enlist or not enlist in distributed transactions. It’s still annoying to try and build a system-wide solution (though the event sourcing guys have this more or less in the bag), so until then, I can just use business decisions to guide me one way or the other.

But it is time to let go and stop worrying so much. Honestly, unless your services have downstream side effects, you can safely turn off DTC if your work is idempotent. If you have downstream side effects, there’s a number of paths to choose from. While I’m not saying goodbye forever (still the best solution if it were absolutely free to use), it is time to shop around.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

A recent Shunra study determined the challenges that were most on the mind of performance engineers in 2013. Over 300 performance specialists were asked about their concerns and approaches to performance testing. Data center relocations and consolidations was the third highest concern when it comes to ensuring performance – 42% of respondents indicated DCR performance as a top concern. The only projects receiving more votes were cloud migration and mobile app deployments.

One thing each of these projects, or concerns, have in common is the amount of planning that should go into them before any changes are made. On this webinar, we will discuss planning as a critical and invaluable step in the process.

On a recorded webcast, reveal five risks of data center relocations, and what you can do to avoid them. Watch the webcast: Five Risks of DCRs and How to Avoid Them.

Webcast Summary:

Misaligned expectations

Often, a move or consolidation is driven by a desire to reduce Operating Expenses or upgrade technologies like new, more powerful servers, better power, or better HVAC capabilities. However, better doesn’t always mean faster. The data center represents only one factor contributing to application performance. You have to think about what happens outside of the data center, and how network connections from the end user to the Cloud are impacting user experience. In fact, applications normally exhibit WORSE performance after a DCR, despite upgrades in hardware, and, if you’re not prepared for it, it can be a career-affecting event.

Shunra summary of impact from 150 data center moves

Not showing measurable value

We talk about planning, and that’s because a data center move or consolidation can be high risk. But that risk comes with reward. There is a motivation behind the move; there is some business value that is expected to be gained, and that business value should be communicated. Enterprises need to define the expected benefits and communicate those benefits to all IT constituents so they have a vested interest in the success of the move and understand how business will be impacted. If you don’t know the value, then you can’t understand the true cost of failure.

Not understanding topology and networks

On this webinar, our feature presenters talk about aligning expectations and understanding intended value. There is a complexity to today’s applications that must further complicate any changes made to a data center. You look at how apps have evolved from client-server, to three-tier and to distributed architectures with dozens of dependencies or services outside of the corporate firewall; not to mention the additional communication layers presented by mobile and Cloud. So how does this complexity affect data center relocations and consolidations? Listen to this webinar to hear Todd DeCapua, one of our feature presenters, talk about:

• Application topology/fingerprint in relation to network
• How will apps behave after move, and planning move groups and testing move groups
• Infrastructure supporting apps
• Transaction stitching

Skipping tests in areas of impact, risk, and failure

A test environment needs to accurately reflect the real-world. The test environment is only yielding accurate test results if the environment includes reliable virtualized users, networks and services. Todd and Marty Brandwin, another feature presenter, talk about how you don’t need to virtualize every piece of equipment to test properly. This is a very common misconception that leads many well-meaning people to avoid testing completely. What you really need is to virtualize the BEHAVIOR of the network, from client to server, from server to database, from application to third-party services. So the good news there is that we have tools today that can do this very easily and automatically.

Lack of DCR experience

There’s a lot to consider – what to virtualize, how to virtualize, how to test with those conditions and what to test. The remarkable thing is that many of our customers call us after disaster strikes. If your applications fail, is the DCR still a success? If you move to a “green” facility and reduce your carbon footprint but fail to deliver product to your customers on time, is your executive team still happy? If your failure makes news on social media or, worse, in the press, can you still feel good that your servers now have faster CPUs? Every customer is different. Every DCR is different. 2013 is a major year for DCRs, and our experience at Shunra teaches us that most DCR project teams only do one large DCR in their career, which is why it is sometimes referred to as a “career-limiting project” or a “career-affecting project.” The lack of experience can contribute to a DCR failure. By partnering with an expert, you can reduce that risk. On average, each one of our engineers has conducted a DCR 16.2 times. Through our experience, we have developed a proven four-step DCR methodology that avoids costly failures. Read more about the methodology.

“I am proud because of” is the opening line of three software testing professionals sharing this lightning talk session with test as its main theme. Martin Karlsson from Lundalogik will share how his company uses dogfooding for ensuring quality. Their administrative staff uses test versions of their own products in their daily work. Mattias Gustavsson [...]

Mobile changes the software development and testing process. As developers invest in shorter release cycles and continuous delivery due to customers’ demands for new and faster functionality, QA teams are faced with mounting challenges. The multitude of releases, devices, form factors, operating systems revisions, networks and services that QA needs to deal with is staggering. The fact that Mobile applications quickly become the face of the company and their quality reflects heavily on the way users perceive corporate brand doesn’t help Development, QA and IT managers sleep better at night.

It is no secret that Development and QA managers are looking for solutions that will help mitigate the risks involved with endeavors like mobile app deployments. Unfortunately, few solutions are rising to the challenge. Solutions do exist today that allow automated testing on multiple devices, leveraging virtualized infrastructure and services for testing application performance limits. These solutions are powerful and can be very helpful raising release quality; however, they tend to overlook a single, critical aspect that heavily influences end user experience – the network. This blind spot in traditional testing processes threatens application success and, as a result, the business value of the application.

With mobile, the network is paramount. As developers and testers, we must ask:
• How will the application behave when there is low signal strength?
• How will the application perform when switching between one cell tower and the next?
• How will variability in networks and user locations impact application performance for the end users and backend infrastructure?

While seemingly daunting, this challenge does have a solution. It is possible to test how users will experience an application on different networks. In simple terms, the solution is to use tools that impair the network traffic between application components in a manner that resembles the way the application is used in the real world.

The real problem is awareness of the availability of a solution to the challenges listed above, and ensuring developers and QA are actually taking advantage of the mobile app performance testing capabilities they need. Traditionally, the network and its impact on user experience has not been well understood or even of primary concern for developers and QA. Mobility (and Cloud) is changing that.

Often developers and testers take the approach that it is enough to ensure the mobile application can communicate with the application backend servers – “after all performance and load testing will find the breaking points”. This approach shifts the resolution of network related issues to the right in the development cycle, where the cost of failure is much greater. With this approach, best case is that network related problems will be found at the performance testing stage. In the worst case scenario, problems will be found by end users, thus impacting business.

As development and testing professionals, we must strive to find issues with applications as soon as possible and fix them before creating a negative end user experience – in other words, shift left. The last thing any of us need is a design failure that is only found after the application development is finished, forcing unnecessary remediation efforts and often re-design that could have been avoided.

Instead of relying on developers and QA to remember to run their tests over varying network conditions, consider making network virtualization part of an enterprise testing infrastructure. If even a few testing machines behave like they are deployed in different parts of the world with different carriers, the network impact of those various locations will be visible from the first test.

From Shunra’s perspective, the steps to enable accurate, reliably predictive test environments follow:

1. Measure or look up the network characteristics of the locations of most concern.
2. Configure one machine or VM to work as a router and install a network virtualization for software testing tool on it. Ideally, the network virtualization solutionallows configuring multiple network locations in a single execution. If all testing is done on the same virtual machine host, one VM can be configured to act as a router.
3. Configure all testing machines to route traffic through the above router machine. On a VM host machine, configure the virtualized network using the VM host tools without needing to load and configure each VM individually. In some cases, this will not even require modifying the routing tables. This settings will persist across VM snapshots and is a lot easier to maintain when network topology changes.
4. Configure the network virtualization tool on the router machine to impair network packets coming from all the connected machines – each machine uses its own location information captured in step one – and run it continuously.
5. Ask your QA and Developers to run tests using these test machines.
6. As tests run, network packets are routed through the router machine and are impacted by the network conditions already defined. Note that the person running the tests does not need to have any control on what network condition each machine gets As that can be pre-configured; the tester does not even require access to the emulation.
7. When using real devices, configure them to connect to a wireless network that routes traffic through the same router machine or use a proxy. Network emulation can be modified so each device will operate under different virtualized network conditions (3G, 4G, Edge, etc).

In conclusion, it takes just a few simple steps to enable a very robust testing environment that incorporates virtualized production network conditions for all tests, without changing the way development and QA teams work or the tools they use. Developers and testers do not need to maintain, know, or even care about the virtualized networks, but they will see network related problems emerging early in the development cycle. Performance testing and the ability to accurately predict end user experience will “shift left” in the development lifecycle when it is easier and more cost-effective to find and remediate problems.

Moq has been for a long time my favorite tool to do mocking. Today, I’ll be introducing another tool I’ve recently start to use.

While Moq was more based around creating a mock, configuring it and then retrieving the object, NSubstitute is more about creating the object and then configuring it.

In NSubstitute, there is no direct concepts of Mock that is presented to the user.

As an example, here is a simple way to do a mock:

IProductRepository repository = Substitute.For<IProductRepository>();

That’s it. As of this moment, you have a mocked repository. Injecting it is very simple at that point.

Since we don’t have a Mock object to work with, how do we go and configure our mock to return what we want?

NSubstitute include an already familiar concept called "Extension Methods" to our users. The one that is going to be used the most is “Returns”. There is two available signature for Returns. Let’s see the decompiled signature for “Returns”.

public static ConfiguredCall Returns<T>(this T value, Func<CallInfo, T> returnThis, params Func<CallInfo, T>[] returnThese)
public static ConfiguredCall Returns<T>(this T value, T returnThis, params T[] returnThese)

You return an instance that has already been built or you return a function that will build (or return) the instance at the moment of invocation. As for the array at the end, those are what is going to be returned/invoked in subsequent calls.

That’s really as simple as it get. Since mocking framework are supposed to be easy to use and not get in your way, I think that NSubstitute might have just taken the place of Moq for me as my go-to framework from now on. Simple, lightweight… I like it!

Installing NSubstitute

Website / Source / Nuget

Nuget command line:
Install-Package NSubstitute

A use case I’ve always been pondering about is how to create a small popup that will tell the user that an operation has succeeded or failed.

What I usually did is write by own Success/Error functions to handle displaying the message to the user. Integrate a bit of jQuery here, a bit of jQuery UI here, download a custom script there…

Recently, I’ve found Toastr. What is great about that tool is how it integrates with pretty much anything a designer can throw at you. CSS classes are replaceable, icons are defined inline in the CSS to avoid external dependencies on images, etc.

Basically, you don’t need the CSS file that comes bundled with it. You only need the JS file if you already got the style all figured out.

Here is how I configured it on my end :

toastr.options = {
    toastClass: 'myCustomDivClass',
    iconClasses: {
        error: 'error_popup',
        success: 'success_popup',
        info: 'info_popup',
        warning: 'warning_popup'
    },
    positionClass: '', // I position it properly already. not needed.
    fadeIn : 300, // .3 seconds
    fadeOut: 300, // .3 seconds
    timeOut: 2000, // 2 seconds – set to 0 for “infinite”
    extendedTimeOut: 2000, // 2 seconds more if the user interact with it
    target: 'body'
};

Basically, this will configure a basic DIV tag element and append it to the of the BODY tag. This is very important in some browser because in some scenarios, form elements might appear over the “toast”.

Another basic boilerplate that you might want to add to your code is this:

$.ajaxSetup({
    error: function() {
        toastr["error"]("<h2>An error has occured.</h2>");
    }
});

This will ensure that any AJAX errors that happens within jQuery is handled using Toastr.

Installing Toastr

Nuget Package / Source

Nuget command line:
Install-Package toastr