Mehdi is a Senior Consultant at ThoughtWorks New York working as team leader, mentor and programmer where he helps ThoughtWorks clients build their ideas into high quality working solutions fast. Mehdi started his career as a back-end guy writing C/C++ code for large scale financial systems. Later he switched to .Net and after working as team leader for a few years moved to consultation and worked for Readify, a .Net consulting company in Australia. In the past few years Mehdi has been enjoying web development with ASP.Net, Ruby on Rails and more recently NodeJS. Mehdi also has a passion for software quality. He is a co-founder of and a contributor on TestStack: a collection of free open source frameworks for building high quality tests in .Net. Mehdi is a presenter and a blogger. You can follow his work on his blog.

In the last article I talked about a few ideas and patterns, like the Page Object pattern, that help write maintainable UI tests. In this article we are going to discuss a few advanced topics that could help you write more robust tests, and troubleshoot them when they fail:

In the last article I talked about a few ideas and patterns, like the Page Object pattern, that help write maintainable UI tests. In this article we are going to discuss a few advanced topics that could help you write more robust tests, and troubleshoot them when they fail:Read More…

A few years ago I was very skeptical about automated UI testing and this skepticism was born out of a few failed attempts. I would write some automated UI tests for desktop or web applications and a few weeks later I would rip them out of the codebase because the cost of maintaining them was too high. So I thought that UI testing was hard and that, while it provided a lot of benefit, it was best to keep it to a minimum and only test the most complex workflows in a system through UI testing and leave the rest to unit tests. I remember telling my team about Mike Cohn's testing pyramid, and that in a typical system over 70% of the tests should be unit tests, around 5% UI tests and the rest integration tests.

A few years ago I was very skeptical about automated UI testing and this skepticism was born out of a few failed attempts. I would write some automated UI tests for desktop or web applications and a few weeks later I would rip them out of the codebase because the cost of maintaining them was too high. So I thought that UI testing was hard and that, while it provided a lot of benefit, it was best to keep it to a minimum and only test the most complex workflows in a system through UI testing and leave the rest to unit tests. I remember telling my team about Mike Cohn's testing pyramid, and that in a typical system over 70% of the tests should be unit tests, around 5% UI tests and the rest integration tests.Read More…