Mocking in .NET - Moving From NMock to Moq

Re:Mocking in .NET - Moving From NMock to Moq by InclinedPlane on Wednesday July 14, 2010 @04:17AM (#1513999)

It's interesting to me that languages are still a bit primitive in their seeming indifference to modern software development methodologies.

People often talk about the "next" big languages, and bring up points such as speed, blending of functional/imperative idioms, cross-platform support, etc. But though a lot of this is good, important work it's also very much rehashing old ground. What I think instead we will begin to see within the next decade or so are languages which take the lessons of modern software development practices to heart.

For example, consider modular compilers and the ability to perform source control merges at not just the plain-text line-by-line level but at the parse tree level.

Or, languages designed with refactoring and IDE auto-completion/intelli-sense in mind rather than as a bolt-on after-thought.

Or, more to the point, languages which are designed around the ideas of TDD, BDD, and mocking. To where mocking falls out of the language naturally and effortlessly, or where TDD is as simple and intuitive as REPL. Instead of as it is today, where a lot of this work seems like fighting uphill.

[ Parent | on HN ]

Re:Mocking in .NET - Moving From NMock to Moq by pgbovine on Wednesday July 14, 2010 @04:54AM (#1514038)

totally agreed; there is an abundance of research in the academic literature from the past 15 years that still have not been properly commercialized. technology transfer between academia and industry is often a slow and bumpy process, but eventually the good ideas will find their way into the mainstream, i think

(i don't know why you got down-voted for this comment; i just voted you back up)

[ Parent | on HN ]

Re:Mocking in .NET - Moving From NMock to Moq by InclinedPlane on Wednesday July 14, 2010 @05:56AM (#1514125)

Mocking seems to me to be a perfect example. Of how obvious it is that we are fighting against the flow with so many of our tools and we are merely lacking the advances in language design which embrace these use cases at their heart. It seems very similar to the clumsy, piece-meal attempts at procedural programming through the use of various macros and such-like in the early era of programming, and later of the attempts at object orientation through various techniques and conventions. But none of those efforts were able to fully exploit the potential of procedural programming or object orientation.

You can't just bolt such fundamental shifts in programming idiom and practice onto existing languages and expect to achieve maximum potency. It often takes new languages, which have internalized the "paradigm shift", to fully achieve the potential of transformative development methodologies.

No amount of assembler macros can be as elegant or as effective in facilitating procedural programming as the C language, for example. Similarly, you aren't going to create Python within C unless you already have the idea of Python to work with.

I suspect that these aspects (mocking and unit testing especially) will become ingrained in future languages to degrees we can hardly imagine. I suspect that unit testing will be as much a part of many future languages as loops, assertions, and methods are today, and that running unit tests will be such an integral part of the build process that it will take explaining to describe how it's even possible for them to be apart.

Unfortunately, I think too many language designers are too satisfied with the current state of affairs and don't see the future in these terms.

[ Parent | on HN ]