I am working on a workflow project that has 19 scenarios for testing the whole system and 34 steps.
So, my question is, how can I create an automation test for it?
My current approach is:
Create an integrated test per each scenario, and then create the main system test to run all integrated tests.
using Microsoft.VisualStudio.TestTools.UnitTesting;
using System;
namespace Project1
{
// Unit tests
public class UnitTest_step1
{
public void RunTest() { }
}
public class UnitTest_step2
{
public void RunTest() { }
}
public class UnitTest_step3
{
public void RunTest() { }
}
public class UnitTest_step4
{
public void RunTest() { }
}
// End of unit tests
public class IntegrationTests
{
public void IntegrationTest1()
{
UnitTest_step1.RunTest();
UnitTest_step2.RunTest();
UnitTest_step4.RunTest();
}
public void IntegrationTest2()
{
UnitTest_step1.RunTest();
UnitTest_step2.RunTest();
UnitTest_step3.RunTest();
UnitTest_step4.RunTest();
}
public void IntegrationTest3()
{
UnitTest_step1.RunTest();
UnitTest_step4.RunTest();
}
}
[TestClass]
public class SystemTests
{
[TestMethod]
public void Scenario1()
{
IntegrationTests.IntegrationTest1()
}
[TestMethod]
public void Scenario2()
{
IntegrationTests.IntegrationTest2();
}
[TestMethod]
public void Scenario3()
{
IntegrationTests.IntegrationTest3();
}
[TestMethod]
public void ScenarioN()
{
IntegrationTests.IntegrationTestN();
}
}
}
Best Regards.
Well, in my opinion, the information provided in your question is very abstract and the question is a bit too broad.
The answer depends on how your workflow engine is implemented and what are your system requirements.
Requirements and implementation details are what defines your approach to testing.
I would start with clarifying what kind of steps you have, is there any data context is passed,
what side effects these steps produce (writes data to database, sends events, call other system APIs, etc.),
do steps depend on each other and so on.
Another question is how do you need to assert the results, after each step or after scenario?
The system should be testable and normally, each step should be covered with unit tests.
So, suggested hypothetical approach is to cover each step with isolated unit tests
and scenarios with integration tests.
I came up with a simple example just to illustrate one of the general approaches.
For simplicity, I assume that steps have little or no data context and can be reordered.
namespace Workflow.Test
{
using Microsoft.VisualStudio.TestTools.UnitTesting;
using System;
using System.Collections.Generic;
[TestClass]
public class SystemTests
{
[TestMethod]
public void Scenario1()
{
new Workflow().Run(new Scenario1());
}
[TestMethod]
public void Scenario2()
{
new Workflow().Run(new Scenario2());
}
// The advantage of explicit steps declaration is test readability.
// Declarative approach also enables the further possibility of test generation!
[TestMethod]
public void MoreExplicitAndDeclarative()
{
new Workflow().Run(new List<Type>
{
typeof(Step1),
typeof(Step2),
typeof(Step3),
});
}
// Step instantiation may be needed if you want to parameterize some steps.
[TestMethod]
[DataRow("Custom step")]
[DataRow("Another step")]
public void MoreExplicitParameterizedScenario(string customName)
{
new Workflow().Run(new List<IRunnable>{
new Step1(),
new Step3(customName)
});
}
}
[TestClass]
public class StepsUnitTests
{
[TestMethod]
public void Step1DoesWhatWeWant()
{
// Mock dependencies
new Step1().Run();
// Assert results
}
}
#region Workflow Engine Example
public interface IRunnable
{
void Run();
}
public class Workflow
{
public void Run(Scenario scenario)
{
Run(CreateSteps(scenario.GetStepTypes()));
}
public void Run(IEnumerable<Type> stepTypes)
{
Run(CreateSteps(stepTypes));
}
public void Run(List<IRunnable> steps)
{
steps.ForEach(step => step.Run());
}
private List<IRunnable> CreateSteps(IEnumerable<Type> stepTypes)
{
var steps = new List<IRunnable>();
foreach (var stepType in stepTypes)
{
steps.Add(CreateStep(stepType));
}
return steps;
}
private IRunnable CreateStep(Type stepType)
=> (IRunnable) Activator.CreateInstance(stepType);
}
#endregion
// Step structure can differ according to system requirements.
// We may add data context and link steps into pipeline if needed.
#region Steps
public abstract class Step : IRunnable
{
private readonly string _stepName;
protected Step(string name)
{
_stepName = name;
}
public void Run()
{
Console.WriteLine($"{_stepName} in action.");
Invoke();
}
public abstract void Invoke();
}
public class Step1 : Step
{
public Step1() : base(nameof(Step1))
{
}
public override void Invoke()
{
// do work
Console.WriteLine($"Step1 invoked.");
}
}
public class Step2 : Step
{
public Step2() : base(nameof(Step2))
{
}
public override void Invoke()
{
// do work
Console.WriteLine($"Step2 invoked.");
}
}
public class Step3 : Step
{
public Step3(string customName) : base(customName)
{
}
public Step3() : this(nameof(Step3))
{
}
public override void Invoke()
{
// do work
Console.WriteLine($"Step3 invoked.");
}
}
public class Step4 : Step
{
public Step4() : base(nameof(Step4))
{
}
public override void Invoke()
{
// do work
Console.WriteLine($"Step4 invoked.");
}
}
#endregion
// Scenarios should be as declarative as possible.
// Let's say the scenario is just specification of what steps (step Type)
// and in what order should be executed (List as a non-unique ordered collection).
#region Scenarios
public abstract class Scenario
{
public abstract List<Type> GetStepTypes();
}
public class Scenario1 : Scenario
{
public override List<Type> GetStepTypes()
=> new List<Type>
{
typeof(Step1),
typeof(Step2),
typeof(Step3)
};
}
public class Scenario2 : Scenario
{
public override List<Type> GetStepTypes()
=> new List<Type>
{
typeof(Step1),
typeof(Step2),
typeof(Step4)
};
}
#endregion
}
Related
I have a number of methods that are called on different 3rd party systems. I now have another 3rd party system that will have the same set of methods actioned against it. If both 3rd party systems are connected I will then call the methods on each object in turn.
Currently I have a class that I pass round that I can call the method once and it checks and then calls it on each system that is enabled, this has an instance of each objects classes, similar to this:
public class AACSCaller
{
3rdPartySystem1 _system1;
3rdPartySystem2 _system2;
public AACSCaller(Settings appSettings)
{
_appSettings = appSettings;
if (appSettings.system1Enabled)
{
_system1 = new 3rdPartySystem1();
}
if (appSettings.system2Enabled)
{
_system2 = new 3rdPartySystem2();
}
}
public void Method1()
{
if (appSettings.system1Enabled)
{
_system1.Method1();
}
if (appSettings.system2Enabled)
{
_system2.Method1();
}
}
public void Method2()
{
if (appSettings.system1Enabled)
{
_system1.Method2();
}
if (appSettings.system2Enabled)
{
_system2.Method2();
}
}
}
Is this sensible, as it does seem there maybe a better way and I may well be connecting additional system at some point.
A possible solution here is to define an interface or base class for 3rdPartySystem1 and 3rdPartySystem2 classes, store instances in a collection and call required methods for every item in collection. If only one system is enabled, you'll have only one item in collection, if both is enabled, you'll call them one by one in loop
public interface IThirdPartySystem
{
void Method1();
void Method2();
}
public class ThirdPartySystem1 : IThirdPartySystem
{
//implementation
}
public class ThirdPartySystem2 : IThirdPartySystem
{
//implementation
}
public class AACSCaller
{
IList<IThirdPartySystem> _systems = new List<IThirdPartySystem>();
public AACSCaller(Settings appSettings)
{
_appSettings = appSettings;
if (appSettings.system1Enabled)
{
_systems.Add(new ThirdPartySystem1());
}
if (appSettings.system2Enabled)
{
_systems.Add(new ThirdPartySystem2());
}
}
public void Method1()
{
foreach (var system in _systems)
system.Method1();
}
public void Method2()
{
foreach (var system in _systems)
system.Method2();
}
}
I suggest you to use interface that have Method1 and Method2 methods and then create to classes System1 and System2 that are implements the interface. Where AACSCaller is create you initialize the correct implementation of the interface and in your methods your just Call to the correct instance method without conditions.
public class AACSCaller
{
IThirdPartySystem ThirdPartySystem;
public AACSCaller(Settings appSettings)
{
_appSettings = appSettings;
ThirdPartySystem = appSettings.system1Enabled ? new ThirdPartySystem1() : new ThirdPartySystem2();
}
public void Method1() => ThirdPartySystem.Method1();
public void Method2() => ThirdPartySystem.Method2();
}
public interface IThirdPartySystem
{
void Method1();
void Method2();
}
public class ThirdPartySystem1 : IThirdPartySystem
{
public void Method1()
{
//code here..
}
public void Method2()
{
//code here..
}
}
public class ThirdPartySystem2 : IThirdPartySystem
{
public void Method1()
{
//code here..
}
public void Method2()
{
//code here..
}
}
In the POM model, we ideally tend to have the driver object being initialized in base class. And in the page classed we pass this driver object. But the problem is to avoid passing this object as well and the tests should continue to work in parallel too in XUNit framework. Below is the structure
public class BaseClass:IDisposable
{
public IWebDriver Driver{get;set;}
public BaseClass()
{
if(Driver == null)
{
Driver = new ChromeDriver();
}
}
}
public class Page1:BaseClass
{
public void method1()
{
this.Driver.Navigate.GoToUrl("http://www.google.com")
}
}
public class Page2:BaseClass
{
public void method2()
{
this.Driver.Navigate.GoToUrl("http://www.stackoverflow.com")
}
}
public class TestClass
{
[Fact]
public void Test1()
{
new Page1().method1();
new Page2().method2();
}
}
Now in the above structure if the test executes two instances of the driver object will be created because of OOPS. If we need to avoid this we can the Driver object as static and reinitialize it if the object is null. But this will again fail when we run multiple tests in parallel. Any suggession? Thing I am trying to achieve is that full encapsulation where the Test class should not have any access to Selenium objects. These objects should be only accessible in Page class or its Operation class if we have any.
We need to ensure we create a driver singleton and its threadsafe to run parallely
[TestClass]
public class UnitTest1 : TestBase
{
[TestMethod]
public void TestMethod1()
{
new Page1().method1();
new Page2().method2();
Driver.Testcleanup();
}
[TestMethod]
public void TestMethod2()
{
new Page1().method1();
new Page2().method2();
Driver.Testcleanup();
}
public class Page1
{
public void method1()
{
Driver.Instance.Navigate().GoToUrl("http://www.google.com");
}
}
public class Page2
{
public void method2()
{
Driver.Instance.Navigate().GoToUrl("http://www.google.com");
}
}
}
Driver Class will handle the initialization of the singleton and cleanup
public sealed class Driver
{
[ThreadStatic]
public static IWebDriver driver = null;
public static IWebDriver Instance
{
get
{
if (driver == null)
{
driver = new ChromeDriver();
}
return driver;
}
}
public static void Testcleanup()
{
driver.Quit();
driver = null;
}
}
So i'm trying to organize my functions into nested classes so i can call them like: "Player.Trigger_Functions.TakeDamage()" rather than calling it as such: "Player.TakeDamage()". I suppose it is a less efficient way to call the functions the way I'm suggesting but it would help separate the functions into distinct categories while remaining on the same file.
Here is some test code but i can't get it to compile online to see if it works.
(some of the functions need to be able to interact with each-other despite being in separate containers which i think is a problem)
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
public class Program
{
public class meme{
public int thicc = 0;
public oof nest1 = new oof();
public watermelone nest2 = new watermelone();
public class oof : meme
{
public void here(){
thicc++;
}
public void call(){
nest2.here();
System.Console.WriteLine("oof" + thicc);
}
}
public class watermelone : meme
{
public void here(){
thicc++;
}
public void call(){
nest1.here();
System.Console.WriteLine("watermelone" + thicc);
}
}
}
public static void Main(){
meme me = new meme();
me.nest1.call();//adding 1
me.nest2.call();//adding 1
System.Console.WriteLine("here is the current thicc value of the me class:" + me.thicc);
}
}
Ok yeah so this code wouldn't work at all, i didn't put that much thought into it but you get the idea of what i'm trying to accomplish.
You can use interfaces to break up the functionality of your class into related groups.
From this:
class Person
{
void sayHello() { }
void sayGoodbye() { }
void walkForward() { }
void walkBackward() { }
}
Refactor into this:
interface ISpeak
{
void sayHello();
void sayGoodbye();
}
interface IWalk
{
void walkForward();
void walkBackward();
}
class Person : ISpeak, IWalk
{
void ISpeak.sayHello() { }
void ISpeak.sayGoodbye() { }
void IWalk.walkForward() { }
void IWalk.walkBackward() { }
}
class Program
{
static void Main(string[] args)
{
Person person = new Person();
IWalk walk = person;
ISpeak speak = person;
speak.sayHello();
walk.walkForward();
}
}
When trying to invoke a Test from a different class from where it is implemented, it does not execute the Parallelizable attribute, instead, it only executes the methods sequentially ( Alltest_2() and Alltest_1() ). Is there any way to invoke them so that they are executed in parallel?
Here's a code sample:
public class AO_Alarms_4 : AO_Alarms_3
{
[SetUp]
public void DefaultSetUp(){ }
[Test]
public void Alltest_Clases()
{
Alltest_2();
Alltest_1();
}
[TearDown]
public void DefaultTearDown() { }
}
[TestFixture]
[Parallelizable]
public class AO_Alarms_3 : AO_Alarms_2
{
public WebDriverFactory driver = new WebDriverFactory(Utils.Browser);
[SetUp]
public void login_2()
{
//code
}
[Test]
[Parallelizable]
public void Alltest_2()
{
test_2();
}
public void test_2()
{
//code
}
[TearDown]
public void teardown_2()
{
//code
}
}
[TestFixture]
[Parallelizable]
public class AO_Alarms_2
{
public WebDriverFactory driver = new WebDriverFactory(Utils.Browser);
[SetUp]
public void login_1()
{
//code
}
[Test]
[Parallelizable]
public void Alltest_1()
{
test1_1();
test1_2();
}
[Test]
public void test1_1()
{
//code
}
[Test]
public void test1_2()
{
//code
}
[TearDown]
public void teardown_1()
{
//code
}
}
You can't simply call tests yourself and expect to get any of the normal NUnit behavior around tests. For example, NUnit knows what to do when it calls a test with [Parallelizable] on it - and what it does is fairly complicated. Your own call is simply calling the method you wrote.
There is nothing to stop you from calling common methods within a given test, but the tests themselves have to be invoked by NUnit.
If you can rephrase or ask another question about what you are actually trying to accomplish here, we can probably give you some advice about alternatives.
Is there an equivalent of JUnit's Rule in C# ? I mean a way to avoid the repetition the same [SetUp] and [TearDown] lines in several different tests. Instead of:
[SetUp]
public void SetUp()
{
myServer.connect();
}
[TearDown]
public void TearDown()
{
myServer.disconnect();
}
... put the logic in a rule that can be declared as field in several tests:
public MyRule extends ExternalResource {
#Override
protected void before() throws Throwable
{
myServer.connect();
};
#Override
protected void after()
{
myServer.disconnect();
};
};
and then
class TestClass
{
#Rule MyRule = new MyRule();
...
}
You could implement your own TestActionAttribute class that runs your before- and after-test code. If you intend to perform the same action before and after every test, you can define your custom attribute at the class declaration.
e.g.:
[MyRule] // your custom attribute - applied to all tests
public class ClassTest
{
[Test]
public void MyTest()
{
// ...
}
}
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method)]
public class MyRuleAttribute : TestActionAttribute
{
public override void BeforeTest(TestDetails testDetails)
{
// connect
}
public override void AfterTest(TestDetails testDetails)
{
// disconnect
}
}
NUnit works well with tests inheritance, so you can create a base test class with SetUp and TearDown methods:
[TestFixture]
public class BaseTest
{
[SetUp]
public virtual void SetUpTest()
{
//...
}
[TearDown]
public virtual void TearDownTest()
{
//...
}
}
Then create a regular test class that inherits from the base class and it will reuse the SetUp and TearDown implementations:
[TestFixture]
public class RegularTest : BaseTest
{
[Test]
public virtual void MyTest()
{
//...
}
}