Testing

What is Coded UI testing?

Automated tests that drive your application through its user interface (UI) are known as coded UI tests (CUITs).

These tests include functional testing of the UI controls. They let you verify that the whole application, including its user interface, is functioning correctly. Coded UI Tests are particularly useful where there is validation or other logic in the user interface, for example in a web page. They are also frequently used to automate an existing manual test.

https://msdn.microsoft.com/en-us/library/dd286726.aspx#VerifyingCodeUsingCUITCreate

How to register classes in unity?

Register by convention:

RegisterTypes:

Method

Description

Platform

FromAssemblies

Takes as parameters the list of assemblies to scan. Returns all visible, non-abstract classes from this list of assemblies. Optionally, control how exceptions are handled when getting types from an assembly by using theskipOnError parameter.

Desktop and Windows Store apps

FromAssembliesInBasePath

Returns all visible, non-abstract classes from all assemblies located in the base folder of the current application domain. Optionally, control how exceptions are handled when getting types from an assembly by using theskipOnError parameter. Optionally control whether to load system assemblies, dynamic assemblies, and Unity assemblies by using the includeSystemAssembliesincludeDynamicAssemblies, andincludeUnityAssemblies parameters.

Desktop

FromLoadedAssemblies

Returns all visible, non-abstract classes from all assemblies loaded in the current application domain. Optionally, control how exceptions are handled when getting types from an assembly by using the skipOnError parameter. Optionally control whether to load system assemblies, dynamic assemblies, and Unity assemblies by using theincludeSystemAssembliesincludeDynamicAssemblies, and includeUnityAssemblies parameters.

Desktop

FromApplication

Returns all visible, non-abstract classes from all assemblies loaded in the install location of the application. Optionally, control how exceptions are handled when getting types from an assembly by using the skipOnErrorparameter. Optionally control whether to load system assemblies, dynamic assemblies, and Unity assemblies by using the includeSystemAssembliesincludeDynamicAssemblies, and includeUnityAssemblies parameters.

Windows Store apps

Unity Lifetime Managers:

The Unity container manages the creation and resolution of objects based on a lifetime you specify when you register the type of an existing object or on the default lifetime if you do not specify a lifetime manager for it to use.

When you register a type using the RegisterType method, the default behavior is for the container to use a transient lifetime manager. It creates a new instance of the registered, mapped, or requested type each time you call the Resolve or ResolveAll method or when the dependency mechanism injects instances into other classes. The container does not store a reference to the object. However, when you want singleton behavior for objects Unity creates, the container must store a reference to these objects. It also takes over management of the lifetime of the objects.

Unity uses specific types that inherit from the LifetimeManager base class (collectively referred to as lifetime managers) to control how it stores references to object instances and how the container disposes of these instances.

When you register an existing object using the RegisterInstance method, the default behavior is for the container to take over management of the lifetime of the object you pass to this method using the ContainerControlledLifetimeManager. This means that the existing object remains in scope as long as the container is in scope, and it is disposed when the container goes out of scope and is garbage-collected or when code explicitly disposes the container. You can also use this lifetime manager with the RegisterType method to specify that Unity should manage the object as a singleton instance.

The Unity Application Block includes three lifetime managers that you can use directly in your code, but you can create your own lifetime managers to implement specific lifetime scenarios. Unity includes the following lifetime managers:

  • ContainerControlledLifetimeManager. Unity returns the same instance of the registered type or object each time you call the Resolve or ResolveAll method or when the dependency mechanism injects instances into other classes. This lifetime manager effectively implements a singleton behavior for objects. Unity uses this lifetime manager by default for the RegisterInstance method if you do not specify a different lifetime manager. If you want singleton behavior for an object that Unity creates when you use the RegisterType method, you must explicitly specify this lifetime manager. The behavior is as follows:
    • If you used the RegisterType method to register a type, Unity creates a new instance of the registered type during the first call to the Resolve or ResolveAll method or when the dependency mechanism injects instances into other classes. Subsequent requests return the same instance.
    • If you used the RegisterInstance method to register an existing object, Unity returns this instance every time you call the Resolve or ResolveAll method or when the dependency mechanism injects instances into other classes.
  • ExternallyControlledLifetimeManager. This lifetime manager allows you to register type mappings and existing objects with the container so that it maintains only a weak reference to the objects it creates when you call the Resolve or ResolveAll method or when the dependency mechanism injects instances into other classes based on attributes or constructor parameters within that class. Unity returns the same instance of the registered type or object each time you call the Resolve or ResolveAll method or when the dependency mechanism injects instances into other classes. However, the container does not hold onto a strong reference to the object after it creates it, which means that the garbage collector can dispose of the object if no other code is holding a strong reference to it.
  • PerThreadLifetimeManager. Unity returns, on a per-thread basis, the same instance of the registered type or object each time you call the Resolve or ResolveAll method or when the dependency mechanism injects instances into other classes. This lifetime manager effectively implements a singleton behavior for objects on a per-thread basis. PerThreadLifetimeManager returns different objects from the container for each thread. The behavior is as follows:
    • If you used the RegisterType method to register a type, Unity creates a new instance of the registered type the first time the type is resolved in a specified thread, either to answer a call to the Resolve or ResolveAll methods for the registered type or to fulfill a dependency while resolving a different type. Subsequent resolutions on the same thread return the same instance.
    • Using the RegisterInstance method to register an existing object results in the same behavior as if you just registered the lifetime container with RegisterType. Therefore, it is recommended that you do not use the RegisterInstance method to register an existing object when using the PerThreadLifetimeManager.
    • PerThreadLifetimeManager returns the object desired or permits the container to create a new instance if no such object is currently stored for the current thread. A new instance is also created if called on a different thread than the one that set the value. This lifetime manager does not dispose the instances it holds.

https://msdn.microsoft.com/en-us/library/ff647854.aspx

Leave a comment