I think it worth funding a Kickstarter project if it could reduce the time we have to wait by 1 or 2 years.

Sorry, I know this is a disappointment for you.

The problem has less to do with resources and more to do with feasibility. If it were just a case of throwing a year of development into such a feature and there being no further cost involved, this would look much more appealing.

Unfortunately, because Rider is written in Java, the entire UI of NCrunch would need to be reconstructed, along with the layer that connects this UI into the engine. Because of extremely tight performance constraints, the UI for NCrunch is deceptively complex and is built almost entirely on custom controls. All of this would need to be duplicated into a Java based equivalent with an intricate communication system that would touch almost all areas of the engine. Every time a feature is added to NCrunch, it would need to be implemented twice; once in .NET, and once in Java. Every time Jetbrains release a new version of Rider, NCrunch would need to be adapted to simultaneously support the new version alongside all prior versions. The maintenance burden of this feature would be tremendous, it would almost double the cost of keeping the project running.

When you consider that at least 70% of the time spent on NCrunch is spent maintaining integration with the tool stack and software developed by other parties, it's easy to see how a significant increase in maintenance would strangle further development. It's possible to get more capacity (i.e. by increasing team size, changing business structure, etc), but there are other costs attached to this, especially in the areas of quality control and the potential complexity of future features. Integration with Rider has the potential to be highly detrimental to NCrunch.

A feature of this size would need to have a really strong business case behind it, or it would need to be in the strategic path for the development of the product. In regards to the former, I am not presently convinced that the potential size of user base on Rider would be big enough to warrant the costs involved in integration. In regards to the latter, it's never been the goal of NCrunch to integrate with everything under the sun. I founded the project to push boundaries and discover new ways of working. It's very hard to do this when you're tied down in a web of integration points floating in a sea of moving parts.

How deep does the integration with the IDE really need to be for NCrunch to work? I would be perfectly happy with standalone version of Ncrunch that works based on changed files and shows results in its own window. This way you would't need to rebuild the UI in a new language.

Businesswise this could be a nice fit with Microsoft's current strategy of opening up the tool stack.

Another aspect is Jetbrains' view of having another continuous testing tool in their IDE, competing with their own continuous testing feature with DotCover (not yet available in Rider though). You wouldn't want to invest huge amount of money/time just to see JetBrains closing the door for you in order to sell more DotCover licenses.

How deep does the integration with the IDE really need to be for NCrunch to work? I would be perfectly happy with standalone version of Ncrunch that works based on changed files and shows results in its own window. This way you would't need to rebuild the UI in a new language.

Businesswise this could be a nice fit with Microsoft's current strategy of opening up the tool stack.

This is an option that I've considered. It would also work for other IDEs. Essentially, it means trading much of the user experience for eliminating the need to reimplement the whole UI. Unfortunately, this half-way approach would still mean integrating and supporting every version of the IDE that is released. NCrunch does still need to synchronise internally with the IDE's in-memory changes and be able to provide inline results. Having the UI hosted by a separate application would also create numerous UI frustrations that I think would disappoint many people. I just don't see such a design meeting a level of quality that I would feel comfortable with shipping, even though I'm sure many people would feel this approach to be better than no support at all.

Another aspect is Jetbrains' view of having another continuous testing tool in their IDE, competing with their own continuous testing feature with DotCover (not yet available in Rider though). You wouldn't want to invest huge amount of money/time just to see JetBrains closing the door for you in order to sell more DotCover licenses.

This is always a risk when integrating with a product built by another (competing) party, though in this instance I don't think that JetBrains would likely close the door on a plug-in like NCrunch. Integrating NCrunch with Rider would be of value for both products. The same situation currently applies to VS, considering the new Live Unit Testing feature.

It is very sad you hear that there are no plans to integrate NCrunch with Rider. NCrunch is my favorite tool for unit-testing, but since the release of Rider I have completely switched to in for development tool because it's performance outweighed the experience of VS + NCrunch. It means that I will no longer upgrade my NCrunch license. And I am sure that there are many developers that feel the same.

Would it be feasible to act standalone and support the language server protocol? https://microsoft.github...nguage-server-protocol/
As far as I understand it has gained popularity and tools then can have one integration point but work in multiple editors.

Unfortunately, there's no way to provide an acceptable NCrunch experience in Rider without the following:

1. Being able to extract in-memory code text from the IDE2. Being able to extract in-memory project details from the IDE (i.e. XML, dependency information, etc)3. Rendering of coverage markers in the code4. Correct preservation of the coverage marker positioning when the code changes (frightfully hard to do)5. Navigation options allowing ability to direct the IDE's UI to different areas of the codebase according to commands by NCrunch (i.e. Go to test, go to exception line, etc)6. Ability to render stable UI windows in the IDE's process, in a way that won't interfere with the IDE's UI or cause massive frustration by overlapping other windows etc.

Unfortunately, even when cutting the feature-set to its bare minimal, it just isn't possible to deliver the above without deep integration with the IDE. That would mean deep integration and maintained testing with all versions of the IDE and all future versions of the IDE. Which leads us back to the original problems with feasibility and maintainability.

Sorry, I don't see a quick and dirty way to do this that will add value for anyone.

IMHO you should reconsider possibilities. You will greatly increase customer base by1. Including users from OS like Linux and Mac2. TDD is language agnostic. I believe that if you build Rider plugin then you will be able to build plugin for all set of JetBrains products. So how about NCrunch for Java, Python or whatever..

I would buy NCrunch for Rider. So you may count for 160$ for that task ))

You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.