![]() The easiest way to do this is a helper class which has the attribute so SpecFlow picks it up. The next step is to plug this into the SpecFlow model. _functionHostProcess = Process.Start(startInfo) StartInfo.WorkingDirectory = functionAppRootPath ProcessStartInfo startInfo = new ProcessStartInfo(functionHostPath) Var functionAppRootPath = Path.GetFullPath(FunctionAppRootPath) Var functionHostPath = Environment.ExpandEnvironmentVariables(FunctionHostPath) Private const string FunctionHostPath = static Process _functionHostProcess Using this class you will basically call the StartHost and StopHost methods. #DRB3 EMULATOR INJECTOR KILL TEST CODE#Maybe we can code something to iterate the folders and find the most recent or something. Unfortunately I haven’t found a better way to identify the latest version of the emulator. You can see this class encapsulates this in 1 place so its easy to change if your scenario is different or if you want to use a different version of Func.exe. Depending on the Configuration mode you run the tests in you will need to change the path which you point Func.exe to so that it points at the right code to test. #DRB3 EMULATOR INJECTOR KILL TEST UPDATE#Func.exe is installed by the Functions Cli which you get installing the tools for functions and sometimes when you F5 it will let you update to a newer version.There are a couple of challenges we need to take care of: net Process class to start the external process Func.exe. This is how you implement it Step 1 – Function Host Managerįirst off I added a class to encapsulate the management of the function host. Ok so hopefully at this stage you like this idea and want to use it. MY test will test some other thing that the function was supposed to do (eg insert into a database)Īt this point I know my unit testing has tested the lower level code and my Specflow test has tested that my code works properly when its deployed as an Azure Function.My function will execute and return a response.At somepoint the step will call my function over http. ![]() Func.exe is now exposing my functions with http endpoints.The tests will start and load up the functions in Func.exe.The simplest example of this is if your function is using the http binding. ![]() We will then execute the test against the resource our function binding is running against and test that the function behaves as expected. What we want to do is start up the function emulator before we run the tests and load our functions into it so that we can see they are registered and running. ![]() The problem is when it comes to automated testing how do you manage the function runtime emulator so that you can test your functions executing within the functions environment. The picture below shows the functions running in the emulator. If you are not familiar with Functions, the easiest way to see this is by pressing F5 in Visual Studio for your function project and you will see that the function host opens up and shows your functions running. With functions you have a number of different bindings and they can be ran inside the Function host which runs as the executable Func.exe. The main thing that is different between the types of service I mentioned earlier and functions is that normally you would develop web services to be hosted in IIS which gives you a few different activation options but the hosting is fairly easy. Ive used Specflow for years when testing Web API and WCF Services and I was keen to use Specflow when coding Azure Functions within Visual Studio. We usually use SpecFlow to compliment normal unit testing with some automated integration tests which combine the idea of “Does the component behave like we expect it to” with the opportunity to have some tested documentation describing the component behaviour. Anyone who follows my blog will know I am a big fan of Specflow for testing components.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |