Developer Coaching

As a software development and developer training firm we've been involved with 100s of clients and many times that number of students all trying to solve the same core problem: How to be successful and get the best return on investment in completing software development projects and educating developers. For various reasons clients have attacked the problem from a number of angles but they usually involve the two classical approaches of outsourcing -or- sending internal/staff developers to training classes and asking them to complete a project. While there are certainly cases where one or both of these approaches have worked in terms of getting something delivered, both approaches have fundamental flaws that tend to yield sub-par results. When asked, most clients feel that these traditional approaches are far from perfect and tend to have more stories relating unsatisfactory outcomes than success stories or at least make comments like, "It could've been a lot better.". From a pure cost standpoint, the perfect solution for most clients is to have internal staff work on projects or hire additional staff versus paying outsourcing rates. The challenge is in sufficiently training current staff or hiring and training new staff in technologies needed for internal initiatives. There's a growing trend in Developer Coaching where experts join a team to both train developers and help deliver software features. When the project is complete the client is left with working code and staff developers with modernized skills. In most cases, Coaching represents an optimal blend of outsourcing and training. At Visionpace, we have leveraged the skills of our trainers and consultants to create a systematic approach to integrated feature delivery and developer training called "Perfect Coaching". For more information check out http://www.visionpace.com/perfectcoaching.html and download the Coaching white paper at http://www.visionpace.com/coaching.html.

Unit Testing Existing Software

I've said that you can't do unit testing without units. Sounds funny or trite, but is very true. If you are doing Test Driven Development (TDD) and develop the unit in concert with the tests then the unit is built to be testable. Existing software is a very different thing.

Units are usually classes. It is also possible to treat individual programs as units. If you are working in a language like Visual FoxPro a PRG or a collection of functions in a PRG can be units. The definition of a unit that I'll use here is a single class or function that can be isolated. If the unit can't be isolated then you are essentially doing integration or maybe even system testing. Existing software that instances classes, accesses the database or other types of external access is very hard to isolate.

Unit testing should occur when the unit can be fully isolated and all aspects of it's existence and execution can be controlled by the test environment. Ideally the setup and teardown of the test should fully provide all the preconditions and things the unit needs to access. When testing existing software this is harder to accomplish. If the unit accesses the database and processes the data and both returns a result and has side-effects of modifying the database, that unit becomes much harder to isolate and test. To truly isolate it, a fake or copy database would have to be used. Assertions would have to be written to verify the output and the modifications done to the database.

Mock objects can be used to test a unit. A mock object is just an object that fakes the tested unit into thinking that it is the real object that the unit should interact with during it's execution. A mock database would be just enough database to provide the tables and fields that the unit would expect or it could be a copy of the full database with just enough filled in to provide the unit with what it needs.

In theory, you should be able to build enough mock entities to isolate most existing units. The problem is that it takes a lot of work to mock some items. To mock classes that the unit instances you can change the search path or change the loaded environments. In Visual FoxPro you can SET PROCEDURE or SET CLASSLIB to a different path where mocked objects live. An Active-X object could actually be mocked by installing a mock version in place of the real one. This would probably require a test system where only the testing was done and no real execution took place. Databases can be copied or faked. External systems like SQL Server can be faked or re-directed to a copy just for testing. The problem is cost. Some of these operations would take many hours to setup. Thus cost might help decide which existing units can be practically unit tested or will just have to continue to be tested the old fashioned way.

Kansas City Visual Studio 2005 Dev Con

Visual Studio 2005 Dev Con in coming to Kansas City - June 1st - Sheraton Hotel, Overland Park, KS Registration Details

Visual Studio® 2005 and the Microsoft® .NET Framework 2.0 represent the next step in the evolution of the Microsoft developer platform. Be one of the first to dive deep into its many new features including improved Web and Smart Client development, advanced Web Services functionality and improved deployment and management features.

Come and see the all new Visual Studio Team System Suite — a set of highly integrated tools that creates a collaborative team development environment. These tools address the needs of the application architect, infrastructure architect, project manager, tester, and developer.  Learn how Team System will change the way your organization designs and develops software.