Sunday, March 6, 2016

In this post I will try to demonstrate how you can set-up a starting point to use Selenium in Visual Studio 2015 and IISExpress to perform UI tests for different JavaScript and Testing frameworks.


1. Get Selenium IE Driver Server

To start you need to download the IE Driver Server from here
Which is going to have a .exe file which is an application that will run & drive IE. Let's assume we put the exe file in 'C:\Temp'

2. Create an ASP.NET project in VS2015. 

I usually remove the Authentication (Select no Authentication) and also ask VS to create a test project. I called my project Sandbox and the test project is Sandbox.Tests. 

3. Add References using NuGet

Open the Nuget manager and add Selenium.WebDriver and NUnit packages to your Sandbox.Tests project. 

4. Set the project to publish after each build. 

To do so you can add the following to your .csproj file. By default this 'Target' element is commented out 

 <Target Name="AfterBuild"> 
<CallTarget Targets="Publish" /> 
</Target> 
<Target Name="Publish"> <RemoveDir Directories="$(SolutionDir)Sandbox\obj\publish\" ContinueOnError="true" /> 
<MSBuild Projects="Sandbox.csproj" Targets="ResolveReferences;_CopyWebApplication" Properties="WebProjectOutputDir=$(SolutionDir)Sandbox\obj\publish\;OutDir=$(SolutionDir)Sandbox\obj\publish\bin\" /> 
</Target>

5. Ensure Roslyn is copied to output

I faced a problem where CSC was not found by IIS Express to use. If the MS Build does not copy the Roslyn directory to Sandbox\obj\publish\bin\roslyn and browsing to your site in IIS results in an error saying CSC was not found,then you can fix this by adding this post-build step to your project file

    <PropertyGroup> 
     <PostBuildEvent> 
       if not exist "$(WebProjectOutputDir)\bin\Roslyn" md "$(WebProjectOutputDir)\bin\Roslyn" 
       start /MIN xcopy /s /y /R "$(OutDir)\roslyn\*.*" "$(WebProjectOutputDir)\bin\Roslyn" 
     </PostBuildEvent> 
   </PropertyGroup> 

this is added just before 'Project' tag close. 

6. Have IIS Express run before your tests start. 

That is an easy thing to do with a class like this. The important bit where new Process object is created and the path to IISExpress is passed to it and Start() method is called. 


using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
namespace Sandbox.Tests.IISEAutomation
{
    public static class IISExpressRunner

    {
        private static Process _iisProcess;
        public static void StartIis()
        {
            if (_iisProcess == null) { var thread = new Thread(StartIisExpress) { IsBackground = true }; thread.Start(); }
        }
        private static void StartIisExpress()
        {
            var startInfo = new ProcessStartInfo
            {
                WindowStyle = ProcessWindowStyle.Normal,
                ErrorDialog = true,
                LoadUserProfile = true,
                CreateNoWindow = false,
                UseShellExecute = false,

                Arguments = string.Format("/path:\"{0}\" /port:{1}", @"C:\Users\Administrator\Documents\Visual Studio 2015\Projects\Playground\Sandbox\obj\publish", "65001")
            };

            var programfiles = string.IsNullOrEmpty(startInfo.EnvironmentVariables["programfiles"]) ? startInfo.EnvironmentVariables["programfiles(x86)"] : startInfo.EnvironmentVariables["programfiles"];

            startInfo.FileName = programfiles + "\\IIS Express\\iisexpress.exe";
            try
            {
                _iisProcess = new Process { StartInfo = startInfo }; _iisProcess.Start(); _iisProcess.WaitForExit();
            }
            catch(System.Exception ex)
            {
                _iisProcess.CloseMainWindow(); _iisProcess.Dispose();
            }
        }
        public static void StopIis()
        {
            if (_iisProcess != null) { _iisProcess.CloseMainWindow(); _iisProcess.Dispose(); }
        }
    }
}


7. Start/Stop IIS Express as part of testing (MSTest)

Now you can use the above class to control your IIS Express. For MSTest you can use [AssemblyInit] attribute

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using OpenQA.Selenium;
using OpenQA.Selenium.IE;

namespace Sandbox.Tests.CodedUI
{
    [TestClass]
    public class HomePageMSTest
    {
        [AssemblyInitialize]
        public static void AssemblyInit(TestContext context)
        {
            IISEAutomation.IISExpressRunner.StartIis();
        }
        [AssemblyCleanup]
        public static void AssemblyCleanup()
        {
            IISEAutomation.IISExpressRunner.StopIis();
        }


8. Start/Stop IIS Express (NUnit)

for NUnit you use [TextFixture] attribute. The following class is stopping and starting IIS using our helper class

using NUnit.Framework;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace Sandbox.Tests.CodedUI
{

    [SetUpFixture]
    public class NUnitSetupFixture
    {
        [SetUp]
        public void RunBeforeAnyTests()
        {
            IISEAutomation.IISExpressRunner.StartIis();
        }

        [TearDown]
        public void RunAfterAnyTests()
        {
            IISEAutomation.IISExpressRunner.StopIis();
        }
    }
}

9. Add Awesome-font 

Use NuGet manager to add Awesome-font reference. the  '~/Content/css' bundle will include that automatically to your page. 
to test you can put this to see the icon is coming up correctly
    <i class="fa fa-refresh fa-spin"></i>


10. Add RequireJS to your project

Here is a good read how you you can set up RequireJS with MVC.
http://volaresystems.com/blog/post/2014/05/27/Adding-RequireJS-to-an-ASPNET-MVC-project

The summary is that you add require to your bundle.

Thursday, May 28, 2015

UML vs Archimate vs BPMN: Use what where

Modelling languages are developed with the objective of facilitating communication between professionals. Unlike natural languages, they are limited by design to a purpose. Unfortunately, when I think about all the models I have seen in the past few years they have been suffering from either of these two problems:
1. Incorrect usage, as using wrong type of elements and connectors without putting enough effort into trying to learn the language first. Creators of these diagrams usually bring down the model to a PowerPoint diagram with arrows and connectors going everywhere. This can be fixed by proper training and audit of the models by more experienced modellers

2. Incorrect choice of the modelling language. This one results in unuseful and misleading models, even if the modeller is well educated about the language.

I think it is very important to choose the right language for the right purpose. This may seem obvious, but I have seen many senior engineers using for example Archimate to prepare a detailed design of the solution or BPMN to model a execution sequence. I thought having a simple map may help chose the right tool

1. Archimate: This is useful trying to model an enterprise architecture. You should be talking about business services mapping to IT and Software Services and IT Infrastructure. 
For example a good fit would be modelling all the systems that will be available for all business users in let's say operating a Mine. 

What is NOT for is:
a. Trying to model the business processes in isolation in detail. that would be BMPN
b. Trying to model high level design of any solution. That is probably done using UML and you just refer to the highest level of that in Archimate. 
c. Generally any detailed design. Archimate is not good in drill down and linking multi levels of resolution

2. BPMN: It is good for modelling the business process (the business bit is very important). So if you are implementing a Workflow solution BPMN might be usefull before going to WML. But it is NOT useful for
a. Modelling HMI, User Interactions with a screen or a functionality of the system. Entring data into a form can be a step in a process, but not a business process. UML is the way to go with that. 
b. Algorithms. BPMN is not a flowchart describing how an algorithm works. 
c. Data modelling. BPMN allows you to refer to data storages, but that does not mean it can be used to do data modelling. it is not ERD

3. UML: is a very broad & open modelling language and has proven to be very versatile and extendible. But it has roots in low level software design. Class diagrams in UML can be converted to code or vice versa. As soon as you are distancing yourself from the Code, the UML starts to lose relevance and becomes less attractive when there are made-for-purpose competing languages like BPMN and Archimate. 
Modelling a Business Entities as Classes & Objects and then using Sequence Diagram to model a business process is possible, but also can be less attractive than BPMN and Archimate. 

Tuesday, May 12, 2015

Is Enterprise Architect a good drawing tool for Archimate 2

The first time I was trying to model a system in Archimate using Enterprise Architect, I experienced some difficulties in expressing the system using the language.
Today I decided to try to draw the model from Archimate's website (shown in my previous example) using Enterprise Architect.
Though the example on Archimate's website is actually too simple to reflect any real-world problems, still Enterprise Architect feels a bit difficult to use.
The problem was after modelling each layer, to create an overall view I almost had to do everything again. The Diagram Frame feature was distorting the elements and was not showing links such as realizations between layers.
So to actually reproduce that diagram I had to link to every element in a new diagram. That was where I stopped because I expected to be able to aggregate layers into one diagram and link them.

Though in real life this problem does not show up that often because having a single diagram will all layers detailed is sometimes getting too crowded to be useful. But the general feeling you get using Enterprise Architect is a diagram drawing software that different standards have been defined in it without tailoring the software enough to make drawing the diagrams easy for these new standards.

Here is the Archimate Example


and this is what I came up with without having to spend an extra hour working around the issues in the Enterprise Architect

The links between layers are missing and the Technology Layer layout is totally broken. The main Technology layer is fine, but the Frame is distorting the layout. 

I like to see how other tools behave trying to draw this



Monday, May 11, 2015

Do we really need ArchiMate? UML vs BPMN vs ArchiMate (Example)

It is useful to have a look at Archimate website's Example and understand what benefits Archimate provide that is can not be achieved by UML and BPMN. 

The Archimate community is sharing very few examples of Archimate modelling, so we try to take the most of this example
http://www.archimate.nl/en/about_archimate/example.html

As an engineer with an MBA degree I can see that this example is no where near real-life complexities both from Technology and Application layer or business layer. 

Archimate is trying to act as normative framework to document the following
  • Business Roles & Actors,
  • Business Services
  • Business Processes
  • Application Services
  • Application Components
  • Infrastructure Services
  • Infrastructure Instances
This is very useful when trying to very high-level view of the IT system in the organization. 
It is important to remember that there is no way we can put all the details for even one system or business services in a single diagram without having thousands of boxes and lines almost going from any box to the other one. 

UMLDeployment or Component diagram can come into competion modelling the 'Technoloyg' and 'Application' Layers while BPMN can be used to model the processes in the 'Business' layer. 
UML Usecases can be used to model usage of the system, but they fall short on easily modelling how different actors are using different usecases to follow a business process. 
Unfortunately there is no standard way to link a BPMN documentation along UML documentations. 

Wednesday, April 1, 2015

Can TDD be not so good for MES Customization?

Test Driven Development (TDD) has attracted a lot of support and affection. I don't need to write to show how good it is. It has so many fans and sometimes the fans sound a bit like religious people. To them, TDD is the best for every project type and any problem in Automated Test goes back to the "Bad Execution" of the TDD and nothing can be wrong about TDD. If you cast any doubt to the holiness of TDD, they call you an "unbeliever" and label you as the one who does not care about quality at a ll. Also like a religion, they have  non-questionable assumptions and the promises are something sound too good to be true (eternal heaven of no bugs)
Before starting, I like to make it clear that I am an advocate of smart automated testing and this writing is only focusing on blind Automated testing in .Net using test, mocking, expectation and continuous build frameworks trying to achieve a 100% coverage in small teams.
The criticism here are not global and does not apply to every project. In MES projects we need to do small once-off coding projects with moderate mission criticality and these criticisms apply more to these types of projects. I am not talking about a transaction processing system for a bank or stock-exchange or health records system. 
Now Let's Start:

A. Automated Tests are Untested Codes

Automated tests can get quite complex and just like any other code they need testing themselves before being trusted. Should we write unit-tests that test Unit-tests? I've heard some saying "A code without automated unit test is like a code that is not written yet". Does that mean auto-unit-tests are considered not written?. going to the religion analogy, if everything needs to be "created", who created the "creator"? TDD fans, tend to imply that tests are bug-free and their bug-freeness flows down to the code. Ore are we sweeping the problem somewhere else? 

B. Automated Tests Take Time to Write:

Hello-World examples of test/mock/validation frameworks show how easy it is to test with their over-simplified examples. But many times in reality it becomes very difficult to write a true test and even more difficult if you insist on using these frameworks. Unless you are already in heaven, you have limited project time and the time you spend on Automatic tests is competing with the time you could use to do manual tests. Their first defence is that the automated test is going to take zero time to execute and over time you actually save time. But they just assumed the test is going to run for many times, while in reality the change in the requirements or design or a dozen of other things can kill a test before it runs even once on a release version. 

C. Automated Tests Worsens Encapsulation:

The design in a TDD usually has to do serve a double purpose: Functionality and Maximizing Testability. You can end up loosing encapsulation to make code testable. You finds ways to avoid this, but they don't come free. Unless one day .Net and .Net languages are changed to support TDD so that you can test a method without making it visible to normal code, this problem will exist. A Symptom of this is usually having Interfaces for objects for no other reason than being able to write tests easier. 
Again, I know there are ways, techniques, platforms and etc.  to alleviate that, but in reality may Devs sacrifice the encapsulation to do tasks in time. The unmeasurable encapsulation is sold in favour of measurable coverage. 

 D. Automated Tests Need DI:

Do you think DI (Dependacy Injection) or RoC (Reversion of Control) is always a good thing regardless of automatic testing? Well not always. They used to be frowned at because DI usages sometimes can be summarized as using a bucket (Container) of objects or object makers (Factories) that have to abide to certain rules so that the DI creates them in the correct way. More often than you think this "buket" just becomes a badly implemented Context object and acts as an "anti-pattern". The DI framework adds complexity and becomes the core of your solution and affects (ruins?) your object creation design patterns. Bugs in object creation which is an important aspect of an application become more difficult to trace and debug. This is because of a very simple situation: The code you write for object creation, is no longer actually creating the object. You get exception in a misleading location

E  Automated Tests Kill Agility:

Writing tests that go red first and you make them green by implementing means only one thing: You are investing (by writing  test code) in a design that may need to change once you try to implement or showcase it. Implementing a design casts light on issues in the design. Showcasing an implementation casts lights on issues in requirement understanding and subsequently the design and implementation. The idea behind being Agile is to shorten the lifecycle so that we discover the issues earlier. Writing a full test often requires definintion of all interfaces which locks down the design. any change in design means changing all interfaces and automated tests.

F. Automated Tests Mean More Moving Parts:

Signing up for TDD usually requires using more libraries which exposes the project to bugs in these libraries. In an enterprise environments, their usage might not be actually allowed if their support cannot be guaranteed. And once we limit ourselves to the white list, we start having problem writing tests quickly, easily or without breaking the design principles. 

G. It  Too Much Attention Because It Is Quantitative

TDD Fanatics don't deny that the amount of automated tests and percentage of code coverage are not the only important code quality merits, but in reality some of them put too much emphasis on it. The measurable things gets more attention than qualitative merits. This is a common human error. As an example, unless we are a pro, when buying a camera, we tend to put too much emphasis on the camera's resolution because it is a number while the quality of the lens is hard to quantify and gets less attention.  
At the end of the day your code is used by a user which is a human. Or used by another Developer if it is library. Can we write a test that measures how human readable an exception is? Too much TDD focus can causes lack of attention to 
  1. Graceful error handling and display
  2. UI layout and user input validation
  3. Code design (lower level design) and Code comments and readability
  4. Variable , Method and Class naming and organizing

In cases, TDD advocates may end up having 100s of tests checking the business logic, but the Button not being visible to user to actually invoke it due to layout issues.

H. Time/Resource Management Hazard

With test development put first, Devs, Seeing the deadline away spent too much of time writing auto-tests in the beginning of their tasks. Apart from the fact that this results in delays in having any first initial versions, this causes some other issues. The development tasks or subprojects roughly can be divided into two time periods, or as some joke about it the first 90% and the second 90%. We as developers simply suffer from under-estimating and in the first 90% try to do things in the right way and rush up in the second to finish the work.
I call the first half the precious half where you fix something just because you want your work to be perfect. In the second half you fix only if your tester complains, or does not compile or your automatic test is failing. You may even comment out an automatic test in the second half!. 

The quality of code in the first half is much higher than the second. Too much TDD ends up having beautifully crafted tests testing terrible code and until last day the developer could not put himself in the user's shoe to deliver something that he himself as user enjoys. 

Final Words

Again, This is not about all project types, team sizes, and development environments. It is very specific about MES customization. 


Wednesday, November 12, 2014

Do we really need ArchiMate? UML vs BPMN vs ArchiMate

UML and BPMN are two well known modelling languages that when used in combination in software solution delivery project, they can cover a very wide spectrum ranging from cross-organizational business processes to classes that can be used to generate executable code.
The question I am facing now is the necessity of utilizing the ArchiMate modelling language.
While I realize that some elements in ArchiMate do not have direct equivalents in BPMN or UML, but do they actually create enough value to justify introduction of another modelling language?
Some googling shows that the language is used with a vast level of divergence by system architects which questions the clarity and usefulness of the language. After all, for a modelling language to be more effective than natural language, it is expected to provide a consistent and normative way of describing the idea or the physical reality.
Almost every ArchiMate diagram that I've seen, although not being wrong, has been a surprise and difficult to verify and understand.
The current guidelines in ArchiMate about defining the system in three layers are too vague to actually produce good quality design artifacts by system architects.

I have provided an example in a later post

Tuesday, May 27, 2014

The MES Solutions designed for the food, beverage and the pharmaceutical industries need to cover few extra requirements to be used along with eBRS systems. These requirements are mainly driven by regulatory requirements about how process data should be stored and protected to be able to be used as part of batch records.
The US FDA’s CFR 21 Part 11 has become the baseline requirement for MES system used in these industry even outside the US.
An important section of this regulation is the requirement for linking records and signatures :
Electronic signatures and handwritten signatures executed to electronic records shall be linked to their respective electronic records to ensure that the signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means  
MES Systems generally use Encryption Algorithms for Digital Signatures to satisfy this requirement. This means anyone who does not have the ‘Private’ key, will not be able to forge the signature and it is assumed that having access to the Primary Key is not considered ‘ordinary’.
While not explicitly said, using Database level security is not usually considered enough protection against ordinary tempering of the signature and that is mostly because of the preventable but prevalent loose security in DB level in industries.

Engineers frequently ask for and successfully acquire higher access rights that they needed for commissioning, maintenance and debugging systems. By having the access rights to add/update/delete records,  a user can easily clone signature data if they are not digitally signed. 
Homepage
Homepage