Natural Language Testing

[James_McN]

Hi Guys,

This is a bit of a fluffy topic but I'm curious to put it out as a thought.

I went to a talk yesterday on unit testing JavaScript code. One of the key values behind the top tools there is that it is written as a behaviour driven syntax. The idea being that non-developers can easily help define tests and understand what the tests do. An example is the Jasmine framework:

describe("The password module", function() {
  it("should require a minimum length", function() {
    expect(true).toBe(true); //Assertions here
  });
});

This echoes something I heard from a few agile development sources that says that the acceptance criteria for a user story should be writable by the customer/product owner and be directly automatable from this.

What I'm trying to think about is how this applies to LabVIEW. Part of me things that a text parser is an easier way to enter tests in this format, but then the point of LabVIEW is that it is signifcantly easier for non-developers to read anyway.

What do people think about this? are there existing frameworks that can already meet this style of testing?

[tyk007]

From a .NET point of view:

• Specflow allows you to write natual syntax for accetpance tests that can then be automated. This allows user stories to be adapted into key customer requirements (features) and then elaborated on in terms of proving that the features are adequate (scenarios). SpecFlow integrates into most typical unit testing frameworks. Specflow is based on the Gherkin syntax and Cucumber, originally developed for Ruby. It is quite popular with agile teams since it allows a great measure of automation as part of CI.
• A different angle - Fluent Assertions is a package I use as an add-on for unit testing to make the Assert aspect more descriptive. It still utilises the same typical unit test frameworks but provides additional assertion support:
  • 12.Should.Be.GreaterThan(11). 
  • "thisIsAString".Should.StartWith("this").And.EndWith("String")

While I think it is possible to make strides towards more readble, adaptable and flexible test code in LabVIEW, my gut feel is that it is difficult to provide this without some form of generics.

[Thoric]

I think this is incredibly interesting. I'm not sure I understand how one spans the chasm from "human prose" to "operational test" in code, so I'll be following this with interest.