Best Practices for Writing Unit Tests

Here are some principals that will help with successful testing:

• Avoid creating dependencies between tests such that tests need to run in a particular order. Each test should be autonomous.
• Use test initialization code to verify that test cleanup executed successfully and re-run the cleanup before executing a test if it did not run.
• Write tests before writing the any production code implementation.
• Create one test class corresponding to each class within the production code.
• Use Visual Studio to generate the initial test project. This will significantly reduce the number of steps needed when manually setting up a test project and associating it to the production project.
• Avoid creating other machine dependent tests such as tests dependent on a particular directory path.
• Create mock objects to test interfaces. Mock objects are implemented within a test project to verify that the API matches the required functionality.
• Verify that all tests run successfully before moving on to creating a new test. That way you ensure that you fix code immediately upon breaking it.
• Maximize the number of tests that can be run unattended. Make absolutely certain that there is no reasonable unattended testing solution before relying solely on manual testing.

Adpoted from A Unit Testing Walkthrough with Visual Studio Team Test by Mark Michaelis.

Benifits of Team Test

Team Test is a Visual Studio integrated unit-testing framework that enables:

• Code generation of test method stubs.
• Running tests within the IDE.
• Incorporation of test data loaded from a database.
• Code coverage analysis once the tests have run.

Adpoted from A Unit Testing Walkthrough with Visual Studio Team Test by Mark Michaelis.

Assembly Binding Redirection

A binding redirection in an application configuration file for a unified .NET Framework assembly cancels the unification for that assembly.

Explicit assembly binding redirection in an application configuration file requires a security permission. The permission is granted by setting the BindingRedirects flag on the SecurityPermission Class. Managed assemblies have no permissions by default.

The security permission is granted to applications running in the Trusted Zone (local machine) and Intranet Zone. Applications running in the Internet Zone are strictly prohibited from performing assembly binding redirection.

Adopted from SDK.

Determining Which Version of the Runtime to Load

The version of the .NET Framework that an application runs on is determined as follows:

1. If the version of the .NET Framework that the application was built against is present on the computer, the application runs on that version.
2. If the version of the .NET Framework that the application was built against is not present and a configuration file does not specify a version in a Element, the application runs on the latest version of the .NET Framework that is present on the computer.
3. If the version of the .NET Framework that the application was built against is not present and the configuration file specifies a version in a Element, the application runs on the latest version that is specified in the application configuration file and is present on the computer.Adopted from SDK.

Adopted from SDK.

Version Compatibility

The .NET Framework supports both backward and forward compatibility for applications created using version 1.1 only. It does not support forward compatibility in applications created using version 2.0. In the context of the .NET Framework, backward compatibility means that an application created using an early version of the .NET Framework will run on a later version. Conversely, forward compatibility means that an application created using a later version of the .NET Framework will run on an earlier version.

Adopted from SDK.

Identifying Data Stored on the Client for Smart Clients

Here are some guidelines for deciding which data to keep on the client:

• Identify the nontransient data used by the application
• Identify the portion of the application’s functionality to be supported while offline
• Identify data associated with functionality that is time-consuming
• Consider the sensitivity of the data
• Identify minimum system requirements

Adopted from Pro Service-Oriented Smart Clients with .NET 2.0 by By Sayed Y. Hashimi, Scott J. Steffan .

The Challenge With Smart Device Development Using the .NET CF

The real challenge with smart device development using the .NET CF lies in dealing with the device’s lack of resources—memory, power, user interface real estate, and so on.

Here are some guidelines for developing smart device applications:

• Delay CPU cycle consumption: The idea is to be passive and not active.
• Choose optimum algorithms
• Design communication channel use carefully
• Consider the battery supply

Two types of storage technologies are used by smart devices: RAM and Flash. RAM storage technology is considerably faster than Flash storage, but are considered volatile because of the potential for losing data if the battery dies.

Adopted from Pro Service-Oriented Smart Clients with .NET 2.0 by By Sayed Y. Hashimi, Scott J. Steffan .

Mobile Device Supports in Visual Studio 2005

VS 2005 offers a lot of additions to the .NET CF and the IDE related to mobile development. Here is a partial list.

• Smartphone and emulator improvements
• Added a host of additional WinForms controls and a richer design-time environment for
  the .NET CF
• Creating solutions that contain unmanaged and managed projects
• Debugging from managed to unmanaged code, and vice versa. You can even attach to a running application on a smart device.
• .NET CF 2.0 supports the latest additions to C# language (such as iterators, generics, partial classes, and anonymous methods). It also supports C++ (MFC 8.0 and ATL 8.0).
• Added managed APIs for Bluetooth, Telephony, Pocket Outlook (POOM),
  the Message Application Programming Interface (MAPI), and Short Message Service (SMS).
• You can do COM Interop with Visual Studio 2005 and .NET CF 2.0
• Having additional performance benefits in its core execution engine and the
  ADO.NET and XML APIs
• Improvements in the CAB building facility

Adopted from Pro Service-Oriented Smart Clients with .NET 2.0 by By Sayed Y. Hashimi, Scott J. Steffan .

The .NET CF Shipped With Visual Studio 2003

Here is a summary of the facilities in the .NET CF that shipped with Visual Studio 2003.

Languages -- All of C# and a subset of VB .NET
Data -- SQL Server and SQL Server for Windows CE
XML -- DOM and SAX parsing via XmlDocument and XmlTextReader; writing XML via XmlTextWriter (no support for XPath and XSLT)
WinForms -- A subset of the WinForms controls
Graphical Device Interface (GDI) -- A subset of GDI classes
Printing -- None
RMI and networking -- Web services and System.Net namespace
ASP.NET -- None

Adopted from Pro Service-Oriented Smart Clients with .NET 2.0 by By Sayed Y. Hashimi, Scott J. Steffan .

Security Log

The Security log is unlike the Application and System event logs in two important respects. First, in the default configuration it is protected by a strong access control list (ACL) and privilege checks, which limits the set of individuals who can read its contents to local system, administrators, and holders of the Security privilege. Second, and most important, only one entity is allowed to write to the Security log—the Local Security Authority (LSA). This effectively means that every time you attempt to call the RegisterEventSource API for the Security log, you will get an ACCESS_DENIED error, even if you're running as Local System!

On the other hand, any interactively logged on user can read both Application and System logs and write to the Application log.

The Security log write access limitation was relaxed somewhat in Windows Server 2003 without changing the fundamental design by the introduction of a special set of APIs. These APIs use Local Procedure Calls (LPCs) internally to interact with LSA, instructing it to generate audit logs on the application's behalf.

Do not be surprised if you don't see anything in the Security log after successfully invoking the auditing API. The messages will only appear in the Security log if you turn on the Audit Object Access setting.

The caller of AuthzRegisterSecurityEventSource must possess the Audit privilege. Generally, the Audit privilege is held not by individual users (including administrators), but by accounts used for hosting services on the system. By default, this privilege is given only to local service and network service accounts; it can also be assigned by administrators to other service accounts that are used to run the trusted components of the system.

This entire process requires the administrator to set up the security event source in the first place. Assuming that auditing will be performed by a particular application, the security event source would be installed by the administrator at the application's install time, and removed when the application is removed from the system. Although this installation can be performed by direct manipulation of certain registry keys, the recommended approach is to use the predefined APIs AuthzInstallSecurityEventSource and AuthzUninstallSecurityEventSource. Naturally, only administrators are allowed to call these APIs, but the caller does not require the Audit privilege in this case.

In order to obtain the Security event log handle, the caller of the AuthzRegisterSecurityEventSource API must be a process with the executable file path registered for a given event source name at install time.

Adopted from Stay Alert: Use Managed Code to Generate a Secure Audit Trail by Mark Pustilnik.