We know that Python provides a lot of productivity over any compiled languages. We have programming in C# & need to write the unit test cases in C# itself. If we see the amount of code we write for unit test is approximately ten times more than the original code.
Is it ideal choice to write unit test cases in IronPython instead of C#? Any body has done like that? I wrote few test cases, they seems to be good. But hairy pointy managers won't accept.
There's an obvious disadvantage which is that everyone working on the code now needs to be proficient in two languages, not just one. I'm fairly hairy but not very pointy, but I do see why managers might be sceptical.
Will's answer is good - you're introducing a new requirement for developers.
In addition, what's the tool support like? I haven't tried any of this myself, but I'd want to know:
It could be that all of these are fine - but you should make check them, and document the results.
There are other options as well as IronPython, of course - Boo being a fairly obvious choice.
Python being a much less verbose language than C# might actually lower the barrier to writing unit tests since there is still a lot of developers that are resistant to doing automated unit testing in general. Introducing and having them use a language like IronPython that typically tends to take less time to write the equivalent code in C# might actually encourage more unit tests to be written which is always a good thing.
Plus, by using IronPython for your test code, you might end up with less lines of code (LOC) for your project overall meaning that your unit tests might be more likely to be maintained in the long run versus being ignored and/or discarded.
Very interesting.
What would happen if you write all your code with IronPython (not just the unit tests)? Would you end up with approximately 10 times less code?
Maybe I should learn IronPython too.
Actually testing is a great opportunity to try integrating a new language. Languages like Python shine especially well in testing, and it's a low risk project to try - the worst case is not too bad at all.
As far as experience testing another language in Python, I've tested C and C++ systems like this and it was excellent. I think it's definitely worth a shot.
What Jon says is true, though - the level of tooling for Python in general, and IronPython in particular, is nowhere near that of C#. How much that affects you is something you'll find out in your pilot.
Python is excellent for UnitTesting C# code. Our app is 75% in Python and 25% C#(Python.Net), and our unit tests are 100% python.
I find that it's much easier to make use of stubs and mocks in Python which is probably one of the most critical components that enable one to write effective unittests.
I gotta go with Will and Jon..
I would prefer my tests be in the same language as the code I'm testing; it causes fewer cognitive context switches. But maybe I'm just not as mentally agile as I once was.
I've recently been re-evaluating my testing attitudes after discovering parameterised testing in mbUnit and NUnit. Previously, I recommended Python unittest as a way to automate any testing possible, because of the concise nature and discoverability of the tests.
Parameterised tests allow you to customise the test fixtures with a range of data parameters and thus your C# tests can end up even more concise than Python tests.
[TestCase(12, 3, 4)]
[TestCase(12, 2, 6)]
[TestCase(12, 4, 3)]
[TestCase(12, 0, 0, ExpectedException = typeof(System.DivideByZeroException),
TestName = “DivisionByZeroThrowsExceptionType”)]
[TestCase(12, 0, 0, ExpectedExceptionName = “System.DivideByZeroException”,
TestName = “DivisionByZeroThrowsNamedException”)]
public void IntegerDivisionWithResultPassedToTest(int n, int d, int q)
{
Assert.AreEqual(q, n / d);
}