concordion:run does not seem to work

[Odonno]

I am trying to write a library using a Concordion spec project and I recently splitted some specification files (HTML + CS) into multiple files. Everything worked fine.

Then, I wanted to use the indexes feature of Concordion that give me a glimpse if another spec file succeed or failed from the current file. I figured I need to use the concordion:run property but here is the result I get :

<a concordion:run="concordion" href="DefaultValue.html">Default value</a>

I can assure you the class and the spec files are at the respective location.. The class is using the right namespace too.

[ShaKaRee]

To get it working with Concordion.NET, you need to utilize the default Concordion.NET test runner by using the parameter run="concordion.net" instead of run="concordion"

Probably you need to provide the relative path to the sub specification you are trying to run. Thus, it could be that you need to adapt href="DefaultValue.html" to something like href="path/to/sub/spec/DefaultValue.html"

Please find additional information about the run command in the specifications of Concordion.NET: https://github.com/concordion/concordion.net/blob/master/doc/Concordion/Command/Run/Run.html

[Odonno]

@ShaKaRee I tried concordion.net instead of concordion. Here is what I got :

[ShaKaRee]

Thank you for reporting this bug. It is due to the fact that the concordion.net default runner is set while loading the configuration. I assume you are not using configuration file for your spec projects - are you?

As quick fix I am attaching a new Concordion.NET.dll that should fix this problem. Does this help to execute your specifications with the run command? Concordion.NET.dll.zip

[Odonno]

@ShaKaRee Yeah! Works better now. Is it possible to update the NuGet package so everyone could have the fix?

Thanks for your help by the way.

[ShaKaRee]

Yes, I will prepare a new release of Concordion.NET so that the NuGet package can be updated.

@Odonno From the stack trace I would guess that you are using Concordion.Runners. Could you share your experience? How long are you already working with it? Which NUnit environment are you utilizing to execute your Concordion.NET tests? Why did you decide to use Concordion.Runners instead of the Concordion.NUnit addin? ...

[Odonno]

Yeah. I can give you some feedback if that could be helpful.

I recently discovered Concordion last year, reading a book about the implementation of Lean in softwares. In one part of this book, they talked about BDD and how they used it. They were using Concordion with java and clearly I did not know there was a BDD framework that uses HTML or Markdown as a guide to write specifications. That was a aha moment!

So, I wanted to experiment this framework and I waited for the right side project to work with. Of course, I am more familiar with C#/JavaScript/TypeScript languages so the only option left was C#, even if the framework feels not as complete as the java implementation, like I saw in the docs of the website.

From the first week of this year, I started to write a NuGet package where almost every test cases should be written in HTML and the implementation should follow in C#, in a TDD/BDD way. I found it a little hard to start at first because I was expecting a very simple tooling : using Visual Studio Test and auto generation of tests/files after build but there were more frictions than I expected : installing NuGet package + NUnit package + NUnitTestAdapter package. I am using NUnit v2.6.4 cause I read somewhere >= v3 is not supported. And then I needed to understand the differences between the use of the base class ExecutableSpecification and the use of the ConcordionTest attribute. Found out that ExecutableSpecification worked for me, not the attribute, maybe I missed something...

Well, now the configuration was set up, I started to add HTML file + fixtures/tests + C# code in my library. From this part, everything is really cool, it feels like magic.

Only one thing that bothers me sometimes when I think how this framework can be more awesome and it's about the HTML/MD files. At first, it was a little bit difficult to locate the generated HTML files from the tests. By looking deeply in the docs website, I managed to find them but I realised it could be really good to :

• have a simple way to set the folder of the generated docs website (HTML results), I mean like in the docs folder of the repository
• when using HTML, generate automatically a local website for the specs in a folder of the repo (like a nodejs website)
• when using Markdown, I suppose it will not be really different but it could be more interesting because people could simply read the files from GitHub (instead of opening a browser or whatever)

Well, I think that's it. Like you saw, I am not really familiar with the framework at the moment but it does what it says and that's what is the more important : write your specs, write your code, feel free to conitnue by adding more specs and by improving the code. If there was anything I did wrong, please tell me so I can change things sooner than later.

Hope it can help you. Thanks.

[ShaKaRee]

Hi, Thank you very much for sharing your experience with us. Which book did you read about lean in software, BDD and Concordion? The Concordion.NUnit addin is compatible with NUnit 2.6.4 as well as all 3.x versions, because NUnit 3 can run NUnit 2 tests. I added this information to the Concordion web page – thank you for this hint. When you derive your tests from ExecutableSpecification and it works for you, I would stay with it. The ConcordionTest attribute together with Concordion.NUnit addin work in a similar way. You can configure the location where your generated docs website (HTML results) are placed as follows: http://concordion.org/dotnet/Concordion/Configuration/BaseOutputDirectory.html Additionally, you can configure the input directory, where your spec files are located: http://concordion.org/dotnet/Concordion/Configuration/BaseInputDirectory.html This is used in the Concordion.NET project itself to have all specifications in a central “docs” directory. This page shows you the configuration options of Concordion.NET in general (sorry for the old design B-) https://rawgit.com/concordion/concordion.net/master/doc/Configuration.html Could you explain in more detail your idea of generating a local website for the specs in a folder of the repo (like a nodejs website)?

[Odonno]

I read Lean from the Trenches by Henrik Kniberg. A really to understand Lean and applying it to an Agile and large software project. But like I said, Concordion is briefly explained in this book.

About the BaseOutputDirectory, I see you can set an absolute path (using C:/) but what if I want to put a relative path?

About generating a local website for the specs, it is not mandatory, But, I can share it with you. I mean having a (possibly nodejs) project that :

• locally watch changes in the docs file and execute tests in Visual Studio
• can also be easily pushed to a remote server (accessible through the web, like a github pages)

[ShaKaRee]

Yes, you can use also a relative path as configuration of the BaseOutputDirectory. btw a relative path is used for the BaseInputDirectory in the Concordion.NET project itself: https://github.com/concordion/concordion.net/blob/master/Concordion.Spec/Concordion.Spec.config

[ShaKaRee]

@Odonno The nuget package is updated. :-) Could you test it and confirm that the fix is working with the nuget package properly?