Is there a way to inject custom logger into Specflow framework to capture beginnings and ends of the steps when using NUnit, or any other supported testing framework apart from XUnit? This help page (and Github issue) shows that with XUnit you can use its ITestOutputHelper to inject custom logger that would gather in the right order both Specflow logging as well as any additional logging that is present in steps.
I am using Context Injection and dependency injection with Autofac to setup all the parts of the test framework. And I understand how to inject any type of logger into Binding classes.
I wonder if it is possible to adapt current standard Microsoft.Extensions.Logging.ILogger<T> to be used for Specflow, step definitions, and other parts of the framework, so that it captures the full flow of the scenario. Or should I write Before/After hooks to get Scenario/Step definitions.
Related
I have made a project in Umbraco using backoffice completely.But Now I am trying to apply concept of dependency injection(which I may have used in past..but not by that specific name) in that project.
and after loads of searching.I now know the concept of dependency injection(I think),in which we are supposed to use classes and constructor to restrict the input supplied to a function in terms of type,value.
But how am I suppose to make that umbraco project from that.I once tried making a strongly typed.It looks much like that which I am supposed to do now.
I also took reference from these articles.
Is it possible to use dependency injection with Umbraco 7 ContentService event handlers?
Why does one use dependency injection?
But still I am kind of stuck..Is there any other way to do unit testing in umbraco.
Yes, you can! :)
Basically, the starting URL for using IoC and DI with Umbraco was already shared. It's here: https://our.umbraco.org/documentation/reference/using-ioc. You can of course use any of the avaialable containers, the example is just for autofac. You just need to remember to initialize container when Umbraco starts (using event handlers).
For Unit Testing resources I would point you first to tests made by Umbraco itself: https://github.com/umbraco/Umbraco-CMS/tree/dev-v7/src/Umbraco.Tests. You can explore how the core team is testing their code and even reference this library and make use of it in your solution.
There are some other useful materials to start unit testing with Umbraco. To list a few:
http://blog.aabech.no/archive/the-basics-of-unit-testing-umbraco/
http://skrift.io/articles/archive/unit-testing-umbraco-plausible/
http://skrift.io/articles/archive/unit-testing-umbraco-with-umbraco-context-mock/
https://www.youtube.com/watch?v=1xS002NyGnc
I think it will be enough to start doing it.
When modularizing a grails application, when does it make sense to add the module as a plugin vs gradle dependency?
For Example:
akaDomain contains all the domain objects.
akaWebsites contains all the presentation logic.
akaService1 contains some services.
akaService2 contains some other services.
All the websites and services share akaDomain.
Can the domain classes present in akaDomain be used for scaffolding controllers and views in another application like akaService and akaWebsite?
Can this be achieved using plugins or dependency or both.
Please explain what am I missing if I don't make a plugin of akaDomain.
This answer uses plugin to explain how to modularize grails app.
You can definitely use the domains defined in one plugin as the basis for scaffolding in another plugin or in a main application. There are several practical considerations when doing so however:
If you choose to implement UI in a plugin, then you are committing to a UI look and feel that is to be shared across multiple applications. This is often very difficult when doing custom / contract development where every customer wants their own personal look and feel. You will want to think about selecting a UI abstraction as well that allows flexibility on theme support at least. We use Twitter Bootstrap for this purpose but there are several others that fit the bill.
You must manage the dependencies between the "domain/service" and the "UI" plugins. This is true of any plugin ecosystem, but once you commit to abstraction, this discipline is very important or you end up with dependency dead ends or cycles. It is a lot of work, but the pay off for productivity is very high.
As for the question on Grails Plugins vs Gradle dependencies:
Plugins are in fact Gradle dependencies (in Grails 3.x at least). That is, plugin dependency management is implemented on top of Gradle. Plugins provide additional support for integrating into a Grails application that include things like:
Automated spring bean registration and initialization at startup.
Participation in application component reloading.
Artefact definitions and initialization at startup.
So, implement using plugins and you get the best of both worlds.
I'm trying to use SpecFlow for a .net project. I'm new to SpecFlow. The Development team are using NUnit, so it would seem that SpecFlow would be a good option in conjunction with Cucumber. However, the Development team have come back say that SpecFlow cannot be used saying they do not have an API/Service that is available to use at the level required. Currently all of their automated tests are through the UI using Test Complete, I am keen to move to API level testing.
Can anyone explain to me why SpecFlow cannot be used, I'm sorry it's a newbie question but no one can answer it, I've asked everyone I can think of, surely the first steps would be to see if we can use SpecFlow with NUnit but perhaps not.
Can anyone give me a guide on my next steps, how can I be sure this isn't an option without righting it off without concern that it's just being blocked?
Thank you
SpecFlow has a unit test generator that generates unit test code for a variety of unit test frameworks. SpecFlow generates NUnit tests in its default configuration. The getting started page on specflow.org explains a quick way to get up and running with SpecFlow and NUnit, http://www.specflow.org/getting-started/.
If the UI is HTTP based, SpecFlow can be used with WebDriver or another browser automation framework to test the UI. This blog post provides an overview of how to get started with SpecFlow, NUnit and WebDriver, http://blogs.lessthandot.com/index.php/enterprisedev/application-lifecycle-management/using-specflow-to/
I am unclear on the API you want to test. If you could provide more information on the specific API and UI you are trying to test, I could possibly provide some code examples or references for you.
Is the API exposed through HTTP?
Is the UI a web, mobile, or desktop
application?
Have you tried to use SpecFlow at all?
SpecFlow doesn't run tests. It simply maps readable language to tests. If their test can be written as a nunit test, then SpecFlow is available to you to use. With no change, here is how it would look.
Scenario: Running 'testname'
Then I execute the test 'TestName'
You would map that to
[Then(#"I execute the test '(.*)'")]
public void ExecuteSpecificTest(string testname)
{
// Using reflection, execute the method listed
}
Obviously you would want to do better than that. You want a given, when, then so you clearly show the setup, action, and then compare expected verses actual result but it isn't necessary. Best practices however is another discussion.
To sum it up, code is code and SpecFlow simply maps to code. You can use WatiN, WebDriver, or anything else to hook into the UI or an API. SpecFlow doesn't care. It simple executes the methods without knowing what's inside.
So my understanding is that the grails testing framework is backed by JUnit tests.
I am trying to hook in cucumber-jvm, and the simplest way appears to be to have a JUnit test with the annotations #RunWith(Cucumber.class) and #Feature(".")
Those annotations appear to be ignored when I build test classes however. I suspect my groovy test classes aren't exactly picked up as JUnit test cases in the normal way.
Is there any way to get the equivalent of those annotations working in grails?
I am using Cucumber-JVM and Geb to functionally test some of our internal grails apps, using this grails plugin http://grails.org/plugin/cucumber
So far so good, I haven't used the annotations you mention however.
When using a dependency injection container, missing dependencies are detected when you execute resolve. This is at runtime.
This article describes a partial solution. It would help simplify test, debug, and maintenance, but it still requires tests to be executed to validate your behavior (especially if you use the abstract factory sub-solution for runtime resolution):
http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx
When using dependency injection containers, is there a way to determine at statically that all of your dependencies will be resolved?
The Managed Extensibility Framework (MEF) can do this. There are some best practices that you need to adhere to in order for the analysis to be accurate, but the results are otherwise good.
To analyse a set of assemblies a command-line tool is used - see http://blogs.msdn.com/b/nblumhardt/archive/2009/08/28/analyze-mef-assemblies-from-the-command-line.aspx. This can be run from Visual Studio or a build script in a continuous integration server - http://blogs.msdn.com/b/nblumhardt/archive/2009/09/24/debug-composition-from-within-visual-studio.aspx.
You can do it visually (again over a set of assemblies) using the MefContrib project's Visual MEFX - see http://xamlcoder.com/blog/2010/04/10/updated-visual-mefx/
MEF supports this functionality by being both very declarative (standard attributes for configuration) and by using an underlying composition model that works lazily (it can build the graph without creating any instances... Takes a bit to wrap your head around.)
Short answer: no, it can't be done.
Doing this would require being able to represent all components and their dependencies (the container metadata) as a graph, in order to analyze it. Problem is, the more sophisticated the container, the harder it gets to achieve this. Take for example Windsor. Its numerous extension points make the dependencies too dynamic to be represented as a graph. Lazy component loaders, handler selectors, factories, componentmodel contributors, subresolvers, all participate in the process and they can be arbitrary user code, which makes it impossible to analyze statically.
A static analysis might be feasible for a trivial container, but then this hypothetical container would be pretty useless for real-world projects.
So as usual it's a trade-off, and the best we can do is have some tests that exercise the actual resolution of all registered components in the container. StructureMap has a AssertConfigurationIsValid() method to do just that.
Even so, there could be more subtle errors that are not caught by this, such as lifestyle issues.
In addition to what Mauricio said, Windsor 2.5 has a feature that you might find useful when diagnosing issues with missing dependencies or just looking through the components in the container.
I blogged about beta version of it here. It's now quite more useful and as everything in Windsor - it's extensible so you can out your own items on that list.
Maybe not with a dependency injection container. However, you can do dependency injection manually, without a container. For example:
var foo = new Foo();
var bar = new Bar(foo);
var program = new Program(bar);
program.Run();
If it compiles then all the dependencies are there.
However, trouble looms as soon as the dependency graph grows large enough that you can't keep it entirely in your head (espcially with some circular dependencies thrown in the mix). If you do refactorings that involve rearranging of dependencies, then it will become hard work to adapt the order of constructor calls.