Productivity: Testing

In this post Emad Mokhtar asks: I want to know how to test my business logic which is basically related to database, I know dealing with database is integration test not unit test but this is what I want to take care of, weather my Employee entity inserted or not, did my validation work or not, what if I insert Employee and failed when in inserting his/her addresses, and can I connected to database.

On larger projects, where different team members work on features that are dependent on other team members' contributions, the ability to work as if the feature already exists, when in fact those developers haven't completed it, can keep overall progress chugging along. When it comes to web and mobile apps, one of the classic "divides" occurs between client and server. You might have developers focusing solely on the front end or mobile app, with others focusing on server-side concerns, like web services. Have you ever been on a team where the client-focused developers had to wait for server-side devs to complete work on HTTP services before they could continue on? This does not have to be the case. Mocking HTTP services itself isn't difficult – and depending on your client side architectural choices, you can also mock your data using your models/view models. We take a quick look at two of these options in this post.

We asked our users to send in their TDD questions with the promise to answer the best five as blog posts. In this post the first user question for the 30 Days of TDD series is answered.

Testing with mobile clients is difficult, but it’s an essential part of load testing applications today.  A large and ever-increasing percentage of application traffic comes from mobile devices, and the unique interactions and communication aspects of these devices has to figure into how we understand the load on the application. Test Studio 2013 R2 lets testers record test scripts on mobile devices and capture that traffic within Test Studio.  Those scripts can be managed like any other Test Studio script, and played back as a part of a load test.  Moreover, you can set the percentages of traffic from individual ...

As I mentioned in my previous post, TDD is easy to do in a green field situation. However for most developers these types of projects are few and far between. Sometimes the brown field project we’re working on don’t lend themselves to unit testing. In the last post I demonstrated how Future Mocking can help in situations where mocking is difficult due to the use of statically bound dependencies. In this post I’ll show how using strict mocking can help ensure that you’re “after the fact” mocks of dependencies and methods are in line with how these components actually work.