I use a tool called Satisfyr. This tool helps me to keep to the 1 assert per test rule. It is a way to perform lambda-based assertions from within tests. It is written by Daniel Cazzulino (developer of World of VS and Moq to name a few things).
I use Satisfyr when I am testing translations between DTO and Business objects that go through an automapper layer. This allows me to turn this:
into this:
Its just syntactical sugar but it helps me to assert that an object is correct - this includes its properties etc. Hope it helps.
One of my favourite new tools to come across in 2011 is NSubstitute. This a is friendly substitution framework for .net. This will allow me to use these substitutes in place of mocks and stubs. Traditionally I use a mocking framework that requires the use of mocks and stubs. Unfortunately, this type of tool has now become a bit of a hindrance for me. The code that is written to assert behaviour has happened seems complex and is not instantly readable for junior developers. Now this isn’t a tool bashing exercise – this post is to demonstrate that this tool (NSubstitute) has effectively made me see the complexity of my tests. It has made me think about being more expressive in my intent. Its not about the tool itself – its about the concept behind it.
On the commencement of a new project, i tried to show some developers NSubstitute. They liked it – they said on first look it was easy to read test code. I suggested they try it for the new project as it was brand new and had 0 test count. I was immediately shot down due to an apparent “learning curve” and “sticking with what they know”. I understand the learning curve part – learning a new tool is potentially tough as its a real shift in what they know. The apathy of sticking with what they knew really saddens me. If I had this level of apathy, I’d still be working with ASP.NET webforms 2.0 and still not unit testing like I was doing 7 years ago. We should all want to push ourselves a little and move outside our comfort zone in order to mature as professionals. Its effectively how we grow, learn and get better at what we do.
I can understand why a developer would not what to change to a new tool when working in an established project. It would be like a rewrite of a section of the project. It would also take time and money to change. But when it is a brand new project with no current toolset what is the issue? Seems a little strange to me.
From my investigations about this topic of mocks and stubs vs. fakes / substitutes, I have seen that there is a real lack of understanding of the differences between mocks and stubs. This article will not talk about the differences – Martin Fowler has already done this in his article Mocks aren’t stubs and there is no way I could do it the justice he has. This has really led me to the question do we really need to care about the differences of mocks and stubs when we have this level of complexity in our tests?. As a developer who tries to push testing to a team, all I want to do is to take an object or a class and test that some logic or behaviour has happened and I get the correct result. We don’t want to shouldn’t make this difficult for ourselves by trying to decide if the object or class that we want should be a mock or a stub.
I have heard of people who get this concept so mixed up that they try and verify all expectations against stubs so they get passing unit tests when this is of course not correct. This is to show sample of implementation of that test.
This shows a test with mocking and stubbing to check that specific behaviour has happened
The same behaviour using substitutes / fakes to demonstrate how much easier it can be without the layer of complexity (written by Dave Tchepak from NSubstitute). Dave did point out that other tools can drive this expressive type of test and also he could write complex looking tests with NSubstitute as well.
I’m not the first developer to talk about this topic and I’m certainly not the last. I think it’s a topic that requires buy in/ backing from a host of developers who lead the way. When talking about this on twitter, Hadi Hariri said the following:
“People need to understand the difference between state and interaction testing, not stubs/mocks/fakes/dupes/blabla”
This is very true! Let’s remove this barrier of complexity in our tests and learn how to write better tests. It doesn't matter which tool we use to do it. Join me in trying to get developers to take the plunge!
About a year ago (July 2010), I started working with my current company. When I started the team were lacking in process and the process they had was not as useful as it could be for developers. The first thing I done in that team was to restructure the VCS and introduce continuous integration (CI).
The reason I chose these 2 practices first was that the team were not working as productively as they could be. There were no VCS regular check-ins and merging was hell. A good set of practices in VCS and a CI server to help spot merge issues up front was my idea of a step forward.
CI was a tough sell to the team. They didn't like the fact that it took time to introduce, they didn't like the fact that people could see everyone's mistakes and the company wasn't sure of the cost of the products and infrastructure needed. Originally, it was not fully understood why CI would be good for us and what it would help. I examined the current state of development and concluded that due to bad VCS practices it was becoming more and more difficult to ‘ship’ a version of the site. The points were how i eventually sold it:
- earlier notification of integration errors
- elimination of bad reference and dependency management
- raising the confidence of developers
The team had a very bad management of references and dependencies in our visual studio solutions. There were GAC references and files missing everywhere. There was no standardisation of 3rd party tool storage. This led to deployment nightmares as there was a post release scramble to find missing dlls & files and FTP them to the live server. I was able to point out that CI system meant we could find dependency issues and missing files faster (on every check in as it happens).
After a few weeks in place the developer confidence got higher. They were more confident of deployments and the team went from deploying once every few months to weekly then to twice weekly and then 3 times weekly. It became more of a lean production line as something was working on – checked into VCS and then the following day (or 2 days) it went live.
IF you are struggling with selling CI to your company or even if you are trying to introduce your company to CI then the following posts are a summary of the steps I had to go through to get CI integrated into our working practices. It started as a proof of concept, to demonstrate the benefits and it has grown exponentially for me. The posts are:
- Choosing the hardware requirements
- Choosing the correct tool
- How to integrate CI into your first project
- Making the Build Self Testing
- What is the potential of CI tools
There seems to be a lack of understanding about what continuous delivery is. I feel that continuous delivery has an ambiguous meaning to continuous deployment. This post will help to explain my understanding of both terms in relation to my experience of both.
What is continuous delivery?
Continuous delivery is the process of having a shippable product/ piece of software after each check in to source control. At work I work on an up and coming quiz site. On successful check in, i have a TeamCity that fires and my web application is build in release mode, is packaged with the correct 3rd party dependencies and correct web.config transformations.
This application is then a potentially shippable product. In theory, I could open an FTP client and push the package to the correct web server and it would work as expected.
What is continuous deployment?
This is the process of shipping your product after every check in to source control. When starting out it is a very scary thought and really should not be implemented without real thought. In order to implement this in a team, you need to be 100% confident that the work they are checking in is fully tested and works 100% as expected. Unit tests, integration tests and other types of testing will help to ensure this confidence.
GiveCamp UK, a site i look after, is setup in a continuous deployment manner. I have a local git repository and I can check in freely to that repository. When i push to github, my CI server triggers a release build and then actually pushes the changes to the live site automatically.I can make 3 or 4 deliveries a day in this format. I have heard of teams who can do this up to 50 times a day.
In my opinion, continuous deployment is not a natural progression from CI. It will take time for a CI process to mature and help the development team to be more effective in their work. For example, a developer continually forgets to check in files when he checks in, release script fires, files are missing therefore site could not work correctly. Successful deployments would suffer and errors recorded on site may increase. A good CI process will help the developers to stop these types of mistakes.
For me, the natural progression after CI, is continuous delivery. The potential for your application to be in a shippable state after every check in is an achievable goal. Once you deploy these ‘packages’ and the confidence in the process increases could you then progress to automatically deployment as part of the process. For me, its the holy grail of dev ops work although I have read that it isn’t for others. My argument to them would be a quote I once read:
A bad developer will manually carry out the same tasks repeatedly, a good developer will automate the task, a great developer will make the task obsolete.”
I will let you draw your own conclusions as to which of the 3 types of developer in the quote related to CI, continuous delivery and continuous deployment. :)
This post denotes the attributes needed in order to help form an effective team. They are attributes that I have worked to bring to my current team and therefore reflect on what my experience of forming a team.
Process
Some developers and methodologies do not believe in process. Some simply say that process is a means to fail. I believe that this is incorrect – every team needs some sort of basic process. A basic process will help to standardise the way we work, our environment, our development methodology or our release procedures. It helps to make sure that we are all on the same team. The process doesn't need to be strict or detailed – in fact I believe that teams that have processes that are *too* heavy will find the processes getting in the way of actually doing their work.
If the process fails then we have an issue. Lets think about a planning process that has gone wrong (iteration planning). The process details that the developers will have a written specification available before they plan the time needed to complete the tasks. If this is not followed then the task may not be completed within the timelines and this could impact the release of other products and also the schedule of the next feature.
Trust
This is a very important attribute of a team. IF there is little (or no) trust, then the team will not be able to effectively work together. This can be as trivial as trusting that the developer can meet their deadline or that they care enough about their work that they will put as much effort as they can into it. If there is little trust, then negativity and insecurity can creep into a team. Being in a trusting environment helps to breed confidence.
Communication
For me this is the fundamental attribute of a *team*. Let's think of a football team that does not talk to each other. They would be a group of individuals that has no way of working together. So the need for a development team to be able to communicate means they can work effectively not only with each other, but also with the business (understanding requirements) to find solutions to any problems that they are faced with.
If a team cannot communicate, how can we be sure they are able to work effectively? They may duplicate areas of the code, not understand requirements or even start tasks that have already been started by another developer.
Leadership
What a team needs is a leader. I have heard of self managing teams but they feel like a mythical beast to me. A team needs 1 person to make sure they we are all striving for the same goal. The leader can be the voice of reason when it comes to disputes and help to settle those disputes. A good leader has the ability to motivate developers. They can empower developers to make decisions on how things are done. They can help to increase the trust levels in the team with that empowerment.
If the leader is weak then the team can start to disintegrate. This is a bad situation to be in. If we take away trust or communication then the team can start to disintegrate. We *can* live without process and structure but we need strong individuals around to help push in the correct direction and form a set of informal methodologies.there are other attributes required (motivation, passion and a sense of responsibility) but these fall outside the core attributes of the team in my eyes.
So in summary, if a team doesn’t possess the basic attributes needed to bond then they are already starting on the wrong foot. A strong leader will help to cement a team together. The team can start with a sound, simple process and communication which will ensure trust bonds the team further. Keeping a team together is not easy work either – it’s like a relationship – it needs to be worked at. Simple practices, like morning stand-ups and retrospective meetings, will help to keep the bonds intact. I’d be very interested to grow this post with help from the community as to what other attributes they feel is necessary for an effective team to possess.
Today, 06 June 2011, was the second Guathon London run the the DDD guys. On today's session listing was ASP.NET MVC 3, Knockout.Js, C#5 and asynchronous Web applications and cloud computing with Windows Azure.
First on the bill was Scott Guthrie to do a 2 hour round robin talk on building an app using ASP.NET MVC 3, EF Code First, NuGet, and IIS. This was a whirlwind talk as usual as there was so much to cover. It wasn’t anything new to me as I use these technologies on a day-to-day basis at work. I also used them to create GiveCamp UK.
Steve Sanderson then talked about knockout.js, his personal web UI framework. Knockout is a JavaScript library that helps you to create rich, responsive display and editor user interfaces with a clean underlying data model. This library uses an MVVM approach in order to bind data to a UI. The way of writing the code is very nice but I must admit I was not convinced of its usefulness to me in this short introduction to it. this was due to a number of reasons:
- non degradation of the JavaScript
- I have questions about its accessibility
- i have questions about how you would actually write maintainable tests for this framework
This is not to say I hate the framework. This just means that initially I must say that my barriers went up as it made me feel outside my comfort zone. I will have a look into it a bit more before I make my mind up on whether I’d use it or not. Right now I’m unconvinced.
After the lunch break, Steve Sanderson was back on stage to take about the use of the new C#5 features (async and await) in order to create asynchronous web applications in ASP.NET vNext. This mean that Steve showed off some of the new MVC4 features and used a NuGet package, called SignalR. The talk demonstrated how the syntax in MVC4 will be a lot cleaner and readable that MVC3 where we use the Async and Completed methods in order to carry out async tasks. It seems to me that async Task<ActionResult> will be of great use to me in the future.
Steve then talked about taking the real time web beyond ajax. The talk spoke about polling, long polling and web sockets. This was my first sight of web sockets and they look very useful although it was pointed out that it was not ready for production applications yet due to non finalised specification. Steve took the long polling example and showed how we can use async in a chat room and voting application. The demos looked simple and easy to read and the MVC4 code looked good
The last talk of the day was back to the ‘Gu’ himself. This time he was talking on cloud computing. Scott was quick to point out that this was his first time talking about Azure since he took his new job and that even though he had taken that job, he was still very much a part of the ASP.NET team.
This talk was split into numerous parts. The first few pointing out what Azure is, what it’s infrastructure is made up of and how to take a simple application, make it ‘cloud ready’ and then deploy to the Azure platform. The next part focused on fault tolerance and latency and this was useful to see. My experience of developers new to ‘the cloud’ is that they take a web app, deploy to the cloud and this it’s automatically scalable. This is of course not strictly true.
Scott then talked about using servicebus as a message queuing service to help create a more load levelled application. The scalability of applications created in this way, means that instances of an app can be increased at peak times through code, Azure management API or via service configuration file changes. The talk was then refocused on how the cloud has made data storage cheaper and more efficient as the cost has dropped considerably over the years. Storing terabytes of data is now not an issue. It was pointed out that Azure replicated data storage in 3 locations for availability and consistency.
Mentions of Sql Azure and Table storage were made and Scott explained the benefits they bring like auto backups, auto sharding etc. The final demo was federated security using WIF. This allows the use of partner API’s (facebook Id, Google Id, Live id and active directory) in order for users to sign into your website. This was a new thing for me and I am annoyed I didn’t know of it before as it would have made the creation of GiveCamp UK easier.
Overall, I enjoyed the event. Thanks to Phil Winstanley, Dave Sussman and the DDD team for organising the event at short notice. Also thanks to Scott and Steve for coming along to speak. It is great to listen to presenters who really do know what they are talking about. It makes me jealous of all the folks heading to NDC2011 to hear more of these kind of talks.
We have been meaning to write a post like this for a long time but have never really had the audacity to do so. We thought the time is right to do it after a lot of stories we have been reading recently.
Over the past few months we have been seeing more and more articles, reports, tweets and basically any other form of communication where people are really putting down other products, methodologies or even other people. I myself have been guilty of this in the past but I felt as though I had to “grow up”. As We started speaking at various events and talking with other speakers, we saw that we needed to change this attitude; to learn to see issues as not just black or white but grey also.
We feel that, as software developers, we all can create an aspect of crap software. There is no-one on this earth that will create perfect software in their first attempt. This goes for the bigger software houses as well – Microsoft, Google, Novell, IBM etc.. but this doesn't stop us from striving to do so.
Unfortunately the industry we work in seems to thrive on companies trying to make out their product/software is better than the product/software of another company, although this may be standard marketing practice it won't necessarily help gain users since when we developers get our hands on it we can very quickly determine if it is any good or not.
One of the worst examples was witnessed earlier this year during a well known conference. A well known team directly demoed their product against a competitor product and pointed out all the wonderful things that their new product will do over the competition. Whilst the new product may be good, people on Twitter were quickly able to determine the veracity of the claims and tweeted with relish when one was found to be false.
We see other examples of this with developers having problems with TFS in comparison to Git/Hg/SVN, we see it in Win Phone 7 compared to iPhone/Android, HTML5 compared to Silverlight. Its everywhere! Its frankly becoming boring to read, see or listen to. Who are we to tell a company that their software is crap? Or that the software I use is better than what they product?
Continuously criticising something in public, yes I'm looking at you tweeple, just makes you look small for not being able to deal with whatever tool a business has decided to use. You may not like something and you are entitled to your opinions, you can tell the business that there may be something better, but if the business has made an investment and isn't going to change then just shut up, sit down and do your job.
If you keep banging on about how something is bad or a complaining that a situation is unjust then it just starts making you look small, better to keep quiet and demonstrate through actions how there is a better way to do something and talk about the positives, generate a buzz about it and grow support to help you overcome the issues that you are seeing.
Our thoughts are subjective – so what's good for me is not strictly good to you. Our code may be good to us but may be bad for you. I think we all need to get off our high horses and just let people make their own decisions. We, as professionals, should deliver our opinions and then leave it there.
Thanks to Nathan Gloyn for being guest co-author for his post. You can find out more about Nathan at his blog – Design, Code, Release. Also need to thank Dan Kendall for reviewing our post and to keep it from being too wild :)
I am very pleased to be able to write this blog post! GiveCamp is an event in the USA that was founded to bring developers together to help out charity. It has been running successfully there since 2007.
Late in 2010, Rachel Hawley had the idea to try and bring GiveCamp to the UK. Through sheer hard work and determinism it’s happening and today we are proud to release our new GiveCamp UK site:
Why did we choose the October 21 - 23? Its the date of the National GiveCamp in the US! What will you be doing on the weekend of October 21 – 23? I know what I will be doing. You should come along! We could all be part of something very special in the UK. Special thanks goes to Gareth Barker at Union Digital Media for helping with the design of the site. Already people have signed up to contribute – thanks to Leankitkanban, SaaSMadeEasy, Github, HasBean and DiscountASP.NET. More are needed :)
If you have any enquiries about GiveCamp UK then you can get in touch with the team on twitter via @GiveCampUK or via #GiveCampUK or email!
I have seen a lot of job adverts in the past few months. I have even written a few myself for some roles at my current company. As we know job adverts tend to be boring! They suggest the things that the developer needs to be to work in a company.
As a potential employee I sometimes don’t think that’s a great way to attract me to your company. I could pass the interview and take the job then after a few months feel as though the environment doesn’t suit me. What do I do then?
I have just today seen a new recruitment drive by The Site Doctor which aims to cure that exact issue. They have released a new site to help them attract new employees – this is a chance for them to sell their company to you rather than the traditional what can you do for us!
I wish more companies done things like this – its a great way for them to show they are head and shoulders above the rest! Please have a look at the site – I was truly impressed by their attitude!
I have to start by saying this post is subjective. These are my thoughts regarding WebMatrix and what I think it will do to the industry. It is not meant as a jibe against any groups and it is not reflective of my attitude towards any companies. I’d also like to say that I know I’m very late to the WebMatrix party but I have just started using it since OrchardCMS made it appeal to me
What is WebMatrix?
To quote Scott Guthrie - “WebMatrix is a task-focused tool that is designed to make it really easy to get started with web development. It minimizes the number of concepts someone needs to learn in order to get simple things done, and includes and integrates all of the pieces necessary to quickly build Web sites.” From my investigations to WebMatrix and the creation of some OrchardCMS sites, I have to agree with Scott. The is really easy to get something together with WebMatrix.
What do I think is good about WebMatrix?
- WebMatrix has a lot of our of the box templates for CMS sites, blog sites etc.
- It is a lightweight IDE for developing on.
- Has automated deployment out of the box
- Comes bundled with IISExpress
- Comes bundled with NuGet It has a lot going for it. I was able to open WebMatrix, choose a new site from gallery and have an OrchardCMS site running in like 5 minutes. I initially thought this was fantastic! I still do in some cases but I can see this may cause us some problems as well.
- Doesn’t have a drag and drop interface for creating pages :)
What do I think is bad about WebMatrix?
- WebMatrix seems to store dependencies in the bin only so when opening in Visual Studio and clicking rebuild then bin files are lost
- Lack of intellisense support
- Seemingly lack of Webforms support – you cant seem to be able to deal with code behind files
- Data Access is a bit of a delicate issue in WebMatrix but I’m not jumping on that band wagon - EDIT: This needs a post of its own
So is WebMatrix a threat to the role of a professional developer?
According to Microsoft, WebMatrix is targeting those who currently write PHP, Classic ASP and who are new to web app development. I think its a great tool to be able to give new users to get started. This is where I also see a downfall in the product. WebMatrix has certainly made quite an impact on professional developers. More and more high profile figures are starting to talk about WebMatrix. 2 of the most high profile are Scott Hanselman and Rob Conery. They have used WebMatrix as a base for the development of their podcast site – This Developers Life.
From my experience, sometimes companies want web applications delivered fast. IF the company is not a native software company (their main product isn't software) then they sometimes don’t care how it gets made or what is used to make it. From companies I have worked for, if they knew there was a way for less skilled developers, who can be paid less, to create sites fast and get it deployed then they would do it. Those companies don’t really care how a site pieces together or care about its maintainability – once its released its done. There is also the cost – WebMatrix is free. It has site templates out of the box for free – VS2010 Professional is $1k (or thereabouts). Would a company struggling for cash be able to choose the $1k product for one of their developers? OR would they just use the free product that a junior developer can use?
WebMatrix is a great product – it just works! Its nice to use and has a lot of features out of the box. For smaller companies I truly believe that this tool will become very important. They cant keep up with the larger enterprise products. This is why I think that WebMatrix is a threat to software developers. Developers who work for smaller companies either need to start getting used to WebMatrix or companies may look to replace them in order to survive this harsh economic climate. For larger enterprises, if WebMatrix is a good fit for a job then I’d suggest to use it – right tool for the right job and all that. As I said its just easy! It does exactly what it needs to. Its just a tool I know and you still need a good grounding in development practices but lets see what has happened in 1 years time after it has been more widely trialled.
Further Resources: