7

Since it is convenient for the developer, the same paradigm are often used for implementations and specifications, e.g.

  • for testing (e.g. Java for the implementation and unit tests, Scala for the implementation and property testing)
  • for model-based testing (e.g. C# for the implementation and specifications using Spec Explorer, or Java for the implementation and specifications using Conformiq)
  • for verification (e.g. C for some embedded software and specifications in the C-like language Promela for model checking, or Dafny, which integrates implementation and specification).

There even seems to be a trend in this direction.

I always thought using different paradigms would help think on different abstraction levels and more generally in different structures, and that faults could be detected much better that way, when checking the implementation against the tests/specification (similar to using design diversity for fault tolerant systems).

So is it true that different paradigms for the implementation and specification can avoid more faults? Do you have a citable reference?

DaveFar
  • 1,456

3 Answers3

1

This is not completely related, but if you includes formal specification languages, you have benefits with annotating your code with formal invariants and contracts.

See for example the ACSL reference manual, for C. The same goes for Ada which allows forall expressions that are not part of the language, but available for specifications: http://docs.adacore.com/spark2014-docs/html/ug/appendix.html. Also, you could have a look at ACL2.

When it comes to tests, you may want to look at Model-Based Testing: you define a model that is useful only for tests.

It is often easier to describe the test in a functional way clearly conveys what the implementation should do, instead of how.

coredump
  • 6,015
1

I think what you want is some level of formalism, see Formal Methods. This is the only guaranteed way to get less fault by using different paradigms because just using something different also has the potential to give different faults (even fixes produce bugs).

Doing implementation in level closer to math will give the ability to have some level of mathematical proof, which means you will have no fault and potentially eliminate need for testing.

This link From HOL to Haskell and Software Foundations should illustrate ideas of using developing specification in theorem prover then translate it into programming language. One article talks about using Isabelle/HOL and haskell, the other is about using Coq, which then you can translate into scala using some tool.

Because it takes more time to do it formally, only small amount of code are developed this way.

imel96
  • 3,608
0

It's my opinion as a QA person that one doesn't really need different testing paradigims. Many will disagree with this statement but there's only one method necessary which is simply testing all known edge cases of whatever it is. The theory is simply Min, Min-1, Min+1, Max, Max-1 and Max+1, Null and or Empty String. If every one of those edges are tested you have bullet proof code.

People will say nonsense and use fancy terms like end-to-end, black box, white box, grey box, unit test, user acceptance test, unit testing, integration, component and system testing, they'll talk about randomness, statistical approaches. etc. All of the above boils down to Edge cases as the method to use. Edge case tests can be run manually, automated etc.

Finally studies show >70% of all bugs are introduced prior to the developer delivering code to QA. What does this mean? It means the best effort for automation is Unit Test! Now consider this, 90% of all developers say "Unit Testing is not built-in to my schedule"... Result is that non-bullet-proof code is continually being delivered to QA, but QA can only catch maybe 20-50% of all bugs as they can't see the code usually...

Writing test cases in the language the developers use is good because now the developers can contribute and maintain the Unit Test library. QA folks should embed with developers and write tests as the code is being created. Test Stubs can be written just from a specification and make the test almost ready for when code is there.

It is true that developers simply don't have the proper time to develop good Unit Tests given today's fast schedules.

John Peters
  • 177