Every language that supports Object Orientation has a port of xUnit. What about for non-oo languages? Are there advantages, or different ways of doing things, and if so, is there a prototypical example (like xUnit is for OO languages)?
wikipedia has a nice page listing the testing frameworks by language: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks
Related
Whether this question is a wide range or not I would like to ask :
Is it possible to implement aspect-oriented programming (AOP) features into OCaml language?
It is interesting to observe that, in contrast to the traditional
concept of crosscutting in the OO setting where aspects typically
crosscut several classes, the majority of the applications of aspects
in functional programming only involve a single function in the
pointcut. We believe the realisation of this difference as concluded
by this paper is important to both the functional and AOP commu- nity.
There is a pressing need to properly interpret and develop of the
concept of ‘crosscutting’ in the functional setting before functional AOP spreads its wings.
[emphasis mine]
What Does Aspect-Oriented Programming Mean for Functional Programmers? (PDF)
Regardless, there are direct attempts/translations of AOP to OCaml or ML systems. From my comment, I don't find these convincing, and believe that proper use of modules and functors can do a lot to capture the demarcation of concerns. Those direct attempts are,
Aspectual Caml
PolyAml(PDF)
Aspect ML
I have asked a related question, but I did not get a satisfactory answer. So, perhaps I should ask it a different way.
How do large-scale C projects, like Perl or Ruby or even the Linux kernel, handle unit-testings? Or even in any functional language?
I am familiar with Dependency Injection and Abstract Factory for testings in OOP, but I don't see a scalable and manageable equivalence in non OOP. In C or Haskell, for example, there would be layers over layers of functions, higher ones implicitly calling the lower ones. How do I find seams to test just an unit of code instead of all its dependencies?
One way to avoid the need for seams all together is to keep the depths of call-dependency graph very low. Code horizontally rather than vertically, so to speak. Keep as much of the application logic as possible in the "leaf" functions; and make sure the "node" functions do no work other than plumbing the data to other node/leaf functions. Then, test only the "leaf" functions; leave the "node" functions out to integration tests. Is that approach effective?
The largest software today are still written in procedural languages. There must be some methodologies being employed that work. Could someone with experience with large-scale software in procedural languages with good unit-testings comment?
Functional languages have other constructs (than objects) for modularity, such as ML functors. "Dependency injection" is basically a glorified name for "abstracting over things" and has been used for ages in functional languages.
Testing, in all paradigms, should follow the specification boundaries. If you have an idea what a given piece of code (function, method, object...) is supposed to do, you should test against this specification. For leaf functions, this will be unit testing, for "node" function this can be considered "integration testing" if you like, but it's really the same activity.
I think you will find that the same methodologies essentially applies to functional programming, with essentially the same results; in particular, (re)designing code to be easy to test also improves its modularity and maintainability.
designing code to be easy to test also improves its modularity and maintainability.
Not true. Designing code to be easy to test improves the ease of writing test code.
Natural divisions of functional modules usually aren't the most convenient for unit testing. That's why so much Java code these days is broken into tiny, scattered pieces, with each piece mostly not useful by itself.
How does TDD compare with Functional Programming Languages like F# and Erlang?
I haven't actually worked directly with a functional programming language yet, but from what I've seen of it, you have two sides of an equation and they have to balance like in algebra or accounting; this seems somewhat reminiscent of TDD where you define your expected outputs as Assert statements (one side of the equation) and the rest of the functionality goes into a class decoupled from the test (the other side of the equation), except that functional programming IMHO seems a bit cleaner.
Do the two actually have similarities, or am I just overthinking this a bit?
Software Design v Development Methodology
They're orthogonal.
TDD is an approach to developing software which focuses on ensuring correctness by developing tests against specifications before the production code is written. Functional programming is a paradigm for designing and implementing software.
I think TDD and functional programming (FP) are different in that TDD is a methodology and FP is programming paradigm.
I would say that FP help when practicing TDD as FP encourages you to make things deterministic when possible. Deterministic functions are much easier to test than non-deterministic ones.
Chris is correct in saying that they are orthogonal. However, there are some aspects of functional programming that make testing of functional programs a lot easier.
Functional programs are composed from functions and guarantee that the function will behave the same in all contexts. This means that when you test a function in unit test, you know that it will always work this way. You don't have to test whether it works if you plug it into some other environment.
Functions take arguments and return results and that's the only thing they do. This means that you can usually avoid mocking and similar tricks, because you don't need to verify whether a function does some call on some object. You only need to verify that it returns the expected result for given arguments.
Finally, there are some nice automatic tools for testing functional programs. For F#, we have FsCheck (which is based on QuickCheck known from Haskell). These benefit from various properties of functional programs.
So, they both have different purpose and are essentially a different thing, but there are some nice relations (perhaps like a tea and a teapot :-) they are completely different things, but work very well together!)
You're correct that when writing a functional program you might use equational reasoning to derive the definition of a function. However, that reasoning typically doesn't exist in some reified form (such as tests), so it is not generally the case that a function is proven correct in a way that is machine- or human-checkable. It is certainly possible to use TDD with functional languages (e.g. using any .NET compatible TDD library with F#) to verify that functions have been derived correctly, but there are also other testing strategies which might be more unique to functional languages, such as using QuickCheck for randomized specification checking.
I think the similar feel between the two stems from the fact that, with both, functions are supposed to be deterministic. FP functions shouldn't have side effects and side effects in test functions for object orientated code should be removed by injecting stubs.
I am just starting to do Test Driven Development, and I am wondering the major differences between RhinoMock, TypeMock, and NUnit's built-in mocking?
Any information would be greatly appreciated!
TypeMock is a commercial product (meaning you'll have to pay for it) but will allow you to mock concrete objects - unlike RhinoMocks/NUnit/MoQ which can only mock an interface/abstract class. How it achieves this is borderline black magic, but it does some very clever things with the CLR.
This can be particularly useful when you use libraries in your project that don't use many interfaces. So you could, for example, use TypeMock to mock out a LINQtoSQL datacontext, or Sharepoint objects. However, if you are using TypeMock this is no excuse for bad design in your application.
As far as I'm aware, aside from minor syntax differences, most of the mocking frameworks have moved away from the old record/playback model. Commonly, you set up your mocks by writing expectations using a Fluent Interface.
Personally, I have only used MoQ and I <3 it.
A video called TDD - Understanding Mock Objects by Roy Osherove is very helpful in learning the differences of the different mocking libraries. He doesn't go in great detail of every aspect, but enough for you to understand. I hope this helps. Roy is also the Chief Architect for TypeMock and is a very influential figure in the unit testing arena. I couldn't recommend this video enough for someone who wants to learn how to use mocking and also learn about the library's available.
The main difference between TypeMock and the open-source library's is that TypeMock uses the Profiler API provided by Microsoft instead of a dynamic proxy. This allows TypeMock to mock concrete classes and static methods. In case you aren't sure what the profiler is, it is the same API that is used by tools like JetBrain's dotTrace and RedGate's Ants .Net profilers. TypeMock just uses the API in a different way to fake(mock) what you tell it to.
#RichardOD, thanks for the reminder, his book "The Art of Unit Testing" goes into greater detail where the video doesn't. I own the book and it is very informative.
Rhino.Mocks is an open source, continuously developed and improving framework by one of the industry's most prolific developers. It has been around for a while and hence supports quite a few different paradigms for mocking. It can be a little tougher to learn therefore in the sense that you might find tutorials for the "old" way of doing things. Here's a tip, SetUpResultFor() and Expect.Call() are the old ways of doing things. The new way is mockObject.AssertWasCalled().
I have not had any personal experience with these others but...
MOQ is an open source, continuously developed and improving framework by one of the industry's somewhat less prolific developers (as compared to Ayende). It is newer and therefore lacks some features that Rhino.Mocks has. This is usually not a problem since these features tend to be ones that are somewhat deprecated in Rhino. I have heard that because of this it is slightly easier to learn (mocking frameworks aren't hard to learn by the way).
NUnit Mocks is very quaint as far as mocking goes. It doesn't support the currently preferred Arrange-Act-Assert syntax relying instead on Expect-Verify (record/replay). It also relies on strings to identify method and property names instead of lambdas. This makes it significantly resistant to refactoring. This is a serious problem. I would not recommend it.
TypeMock Isolater is a hardcore for-pay mocking framework from a company (owned by?) Roy Osherove - a guy who knows his testing but also has some mildly controversial opinions as to how to apply it. It is really intense as far as what it can do - getting down to the low level and modifying how CLR objects work. The philosophy behind TypeMock isn't really 100% TDD however. Part of the benefits of TDD is that by embracing the limitations of Mocking frameworks you will design better code. TypeMock blasts those limitations to pieces. As far as I know it is mostly used by people who are trying to get code they have no control over under test.
I use TypeMock all the time and have found it to be a very powerful tool that can improve the coverage of my unit tests. This is because I work with SharePoint and only TypeMock can allow me to mock out SharePoint classes - since they are concrete classes and not interfaces.
Mocking SharePoint classes is not possible with RhinoMock, Moq, NUNit, etc since (I believe) they require interfaces to mock objects, rather then being able to mock the actual concrete classes.
If your code does use a lot of interfaces, and you don't require mocking concrete classes then TypeMock is a bit pricey, but for the power you get, it's worth it.
I've been reading a lot about Unit tests and Test Driven developemnt.
Recently, I also read java unit test code.
I however, prefer to develop in Qt. So I googled up "unit testing in c++" and found a host of information about various unit testing frameworks available for C++.
However, I could not find a reliable comparison of the the various frameworks.
So I look to the SO community to guide me through the selection of what may the "best" unit testing framework for c++.
Also, if anybody had specific comments regarding TDD in Qt (especially using Qt-Creator), then they are more than welcome.
Usually use Boost, but if you are using Qt, their QtTestLib might be the better choice.
I would recommend doctest (created by me) - it's the lightest on compile times from all the popular testing frameworks. It is also a direct competitor to Catch which is currently the most used framework - checkout the differences in the FAQ
This seems too be the same question as:
Unit testing in C++ which is actually c++ despite the URL title.
From there, they link to two more SO questions which should help:
Unit testing for C++ code - Tools and methodology
C++ unit testing framework
There is a table comparing all (?) the C++ unit test frameworks available from wikipedia.
There also is an old comparison of C++ unit test frameworks available. I do not think it has not been updated so I mention it as a complement as it's more argumented than the table. It covers, CppUnit, CppUnitLite, Boost.Test, NanoCppUnit, Unit++, CxxTest, especially it does not cover Google C++ framework.
The "xUnit" family of testing frameworks is usually pretty solid (jUnit, NUnit, etc.). I haven't used it myself, but there is a port of jUnit for C++:
http://sourceforge.net/projects/cppunit
Boost is usually a good choice, and it contains a testing framework, the Boost Test Library. I have used it for small test cases and it did what I expected, but I haven't used it extensively like in TTD.
If you want to get off the ground quickly without figuring out how to build a library, there is a single header file include solution, which supports fixtures (setup and teardown), the usual TEST() {} with CHECK_TRUE, etc.
It also has memory leak detection and performance testing capabilities.
https://gitlab.com/cppocl/unit_test_framework