Background:
I am familiar with xUnit family frameworks and have had experience with (shunit2, PhpUnit and simpletest). I am currently trying to find a testing framework for C++. I did a quick search for frameworks using Wikipedia’s list of documented frameworks; however, the framework I would like to use is very difficult to setup and is poorly documented. There is another framework that I have tried that was (IMHO) extremely easy to setup and integrate into my production workflow.
The difference between my framework of choice (the one that is difficult to setup) and the one that I’m currently using (the one that was easy to setup) is compliance with xUnit methodology.
Questions:
1. I have read quite a few articles about xUnit testing frameworks. I believe that they use similar naming conventions and testing methods for their test. Is this true and what are the naming methods utilized?
2. Does staying with xUnit testing frameworks make it easier to run integration tests when using multiple languages?
3. From a training perspective is it more cost effective to teach new programmers a set of tools based on the same concept or different individual tools that do the same thing?
I kept the frameworks that I am looking at anonymous because I am more interested in industry best practices than a comparison of the two said frameworks
7
I’ve found that while a set of tools in the same family might sound like they should all be the same (specifically I’m thinking of log4x, which is an awesome log library and much better than things like the .net logging stuff) it is still different enough in its configuration and use to practically be separate tools.
So I would not stick with a single family of tooling, and would use whatever tool you liked best, regardless of its provenance.
I find this kind of thinking prevalent in the Microsoft world – “we use Microsoft here” and no matter how bad the Microsoft tool might be, or how wonderful the non-Microsoft tool is, some people will simply not use the good stuff, and will stick with whatever Microsoft gives them. (It used to be the same with IBM, and I’m sure other places have the same mindset). The problem here is that they restrict themselves to the idea that there is stuff out there that is actually better.
So use the tooling you think is best. If you (and everyone else) refused to use a non xUnit test framework then there would be little incentive for people to come up with new, better ways of solving the problem. Using the better quality product is industry best practice IMHO.
3
I haven’t done TDD in C++, but I am currently reading Working Effectively With Legacy Code and my first instinct would be to go with something recommended by Michael Feathers.
-
In my experience it’s the concepts that are more important than the names of things. So in the xUnit style, you have the concept of a test suite which contains a group of tests, a setup procedure, and a teardown procedure. The setup is run before every test in the suite, and the teardown is run after every test. So any framework that has these concepts should be easy for someone with xUnit experience to adapt to.
-
Integration tests are a different beast than unit tests. The xUnit style frameworks don’t really focus on integration. Web folks have developed specialised tools that ‘auto-pilot’ a Web browser to test website behaviour, but I believe a more general approach is taken by something like Fitnesse, which lets you specify expected inputs to and outputs from a system, and test those are fulfilled.
I will say that you want to keep an eye on automated tooling–especially to see if your build tool can understand your test framework output and present it in reports, notifications, etc. It’s not enough for a framework to just print out stuff to the console–it has to be able to give you something that your continuous integration system can use to check for build success and test pass/failure (e.g. Travis CI).
-
Not sure I understand this–it seems too general. But see # 1.