I am looking for some tutorials and guides for unit testing on SAP platform.
So far, I have found some mention of ABAP Unit and of Ruby programming language being implemented on SAP software, making it much more interesting option for unit testing SAP software. However, the information is quite scarce and I would appreciate some help on the subject.
The ABAP Unit Wiki on the SDN is a good place to start, as well as this ABAP Unit Best Practices article.
SAPTechnical.com also has an ABAP Unit overview.
And finally, you should check out the links in this question.
Just with regards to your reference to Ruby on the SAP ABAP platform, what you are referring to is "Blue Ruby". This is a project of SAP's research labs and you can find information about it on the SAP Developer Network wiki
In my testing a year ago, I found that Blue Ruby was much preferable to ABAPUnit in several ways, including the ability to be more true to test/behavior-driven-development principles by (for example) writing a test for a method before implementing the method.
Ruby, of course, also has far more and more mature TDD/BDD libraries than ABAP, which pretty much just has ABAPUnit and the eCATT tools. These libraries (RSpec, Cucumber, etc) seem to work under Blue Ruby. Both ABAPUnit and Blue Ruby have improved a lot since I looked in to them a year ago, but only for the better, I think.
There is an excellent course on ABAP Unit on OpenSAP.com. It is called
Writing Testable Code for ABAP
The URL for the course is: https://open.sap.com/courses/wtc1
Detroubulator (http://www.applicon.dk/Detroubulator/) is a unit test tool for mapping programs (XML transformations) running in SAP's PI product. It's written in Java and might be considered a JUnit/Schematron hybrid.
Related
I want to know that,does BDD just work in acceptance test level? If not, does it work in unit test level as well? Does BDD have any suggestion For Unit tests?
thank you
BDD is just a way of defining the specifications for an area of functionality. The idea is to bridge the gap between technical and non-technical people by using human readable syntax of some kind and to use specific examples to define the desired behaviour rather than talking in the abstract. As such it is a tool to help people work together and define the business' requirements for the new functionality. This is the primary point of BDD. Not testing.
The definitions that come out of BDD are however, useful for acceptance testing as they define the expected behaviour that was agreed upon. As such many great tools like cucumber are available to facilitate automation of these scenarios to cut down on your testing time.
With regard to using BDD for something like unit tests, the idea of using BDD and non-technical descriptions is to help involve non-technical people. If there are no non technical people involved in the creation of your unit tests (which I guess is the most likely case) then why bother with it? Technical people can read unit tests that are properly written, just fine. The unit tests that you're writing will come out of the functionality that is described by your BDD scenarios anyway.
However, if there is some technical detail of what you're working on that you're having trouble describing, and your team are comfortable working in a BDD way then definitely give the non-technical language and specific examples approach a go. I just wouldn't bother using the the human readable language version of the example in your unit test.
Edit: After reading xmojmr 's comment about your question, I can absolutely see the benefit of using BDD tools and syntax to make your unit tests more readable/easier to plan out, but I think this is quite different from BDD in general, which is more about bridging a communication gap.
BDD actually started at the class level. The first incarnation of JBehave was a replacement for JUnit that avoided the word "test". It was only later that the system-level stuff came along after Dan North explained mock objects to Chris Matts, an analyst at the time who was learning how to code.
These days, even unit testing frameworks don't insist that you start your test methods with the word "test", and the frameworks for the dynamic languages are pretty much derived from RSpec, which was a port of JBehave's early functionality to Ruby anyway.
So, yes, it's perfectly possible to do BDD at that level.
Of course, alannichols is right in saying that the audience is different, being non-technical.
So why would you want to do BDD?
As Dan says in that first link, it turns out that talking about behaviour is more useful than talking about tests. In BDD, we just avoid the word test. We prefer talking about examples and how things should behave rather than pass or fail.
By having conversations around the desired behaviour of a system or class, and providing examples of that behaviour, you can explore it more easily than when you're talking about testing.
However, because it's a non-technical audience, I find it's enough to put the "given, when, then" in comments. You can see an example here. You don't need an explicit BDD tool.
If you can't find another dev to talk about the behaviour with, I suggest you find a rubber duck.
I am starting a maintenance project where I need to work with legacy code and also create new ones. New ones I can create proper interface based development and I can use Moq to do proper unit testing. I can't use Moq against the legacy code since they do not have proper coding to mock out the objects. Based on the reading, Typemock looks like an excellent fit since I can isolate the object and return what we want when a method is called on legacy objects. I really like the simplicity and ease of development. I would like to know is there any other tools out there like Typemock I should look at before committing to it since I have to pay for it.
Thanks
PS: ours is Microsoft shop we work with C#/ASP/ASp.Net/Silverlight and VB.Net
** I just found that Infragistics have one mocking tool as well.
What you're looking for is a mocking framework that uses the Profiler API. These are the ones that can "mock anything" because they sort of run "underneath" the code being tested.
When considering one of these, you'll want to think about things like:
Integration support: Does it work with the tools you're using? For example, your build server, coverage tool, unit testing tool, etc. Are there any additional tools it comes with (e.g., Visual Studio plugins) that might help you work with it?
Technical support: If something goes wrong or you find a bug in the product, can you ask someone about it?
Syntax/patterns: Does it support AAA testing or is it only record/replay? How easy is it to start working with?
Community and learning resources: How's the documentation? Are there people out there who can answer your more general usage questions or are you "on your own?"
There are three primary mocking frameworks to consider that I'm aware of:
Typemock Isolator - The most mature with a free license for open source projects, but otherwise not free.
Telerik JustMock - New to the scene, but good features. There is a free/limited version.
Moles - Free from Microsoft, though somewhat less easy to integrate with tools outside the VSTS realm.
Full disclosure: I'm a Typemock MVP and I've been using Isolator for a while. It has thus far been worth its weight in gold, particularly in Brownfield development. I will admit in some cases, where it's more Greenfield, I use Rhino or Moq. It really depends on what I'm doing.
In any case, I recommend evaluating each of the tools yourself to see which works best in your environment. Be sure to see how it integrates, how easy it is to get going, etc. for each one, and then make your decision based on your experience in your setting.
I've realised that I really do need to get started on the behaviours and patterns related to unit testing in general and with ruby specifically, as I can then migrate that knowledge to other languages. Are there any really good examples on how to get started? The problem I have is that with the current systems I'm using and working on it seems like getting started with Unit testing is insurmountable.
I've never built a single unit test for operational code other than trying the same fifteen or so online tutorials that show you ruby's core classes seem to function fine. I need to know how to build these tests for my own systems and the mentality of what to look for and test for.
What good tutorials are online that show you how to do more than just test that an assert_true is true and the opposite is false? Even if they're not for ruby, what must-read and must experiment unit testing guide should I read or go over? Preferably one with a step by step tutorial.
Stuff like using these unit tests in actual existing models and frameworks and what to actually test for? I'm still trying to get my head around the testing mentality and I keep getting sidetracked by the different elements. No one's really specifically outlined what mentality you need to approach unit testing with, as all of those who have written guides or tutorials seem to have internalised the logic with which you approach the system.
Any help would be really appreciated.
Technically it's BDD, but I would recommend The RSpec Book because it does a good job of explaining concepts and has extended tutorials. The second section of the book covers Cucumber, so it will teach you that as well.
I know this is a perl tutorial, but I think it's really good for the approach/philosophy: cromatic's and Michael G Schwern's Test::Tutorial pdf. It's the first tutorial I read that said to make your tests fail first, and there's lots of other good tips.
It's really easy to get sidetracked and drawn into details such as code coverage tools like rcov and even more detailed tools such as heckle, flog, flay. These tools are great and they track down bugs but they should be secondary to unit tests being related to design and documentation.
I feel this sums it up - From the agile TDD page
"The act of writing a unit test is more an act of design than of verification."
"It is also more an act of documentation than of verification"
I did some searches on developing a DSL in visual studio. At the beginning, I found out there is a Visualization and Modeling SDK for VS2010. It has a tool called DSL tool. But it seems that it is only for graphical DSL development.
Then I saw some posts saying "Oslo" is a tool for developing textual DSL, which "was" a Microsoft product - Microsoft no longer supports the tool. http://blogs.msdn.com/b/modelcitizen/archive/2010/09/22/update-on-sql-server-modeling-ctp-repository-modeling-services-quot-quadrant-quot-and-quot-m-quot.aspx
Therefore, I would like to know if I want to develop a textual DSL, what tool is the best? What do you think if I implement a DSL parser making use of F# powerpack with FSLex and FSYacc?
I am currently developing several external text-based DSLs using FsLex/FsYacc. I was using a hand parser, but I find the FsLex/FsYacc much easier to maintain in the design stage.
FsLex/FsYacc are not as sophisticated as ANTLR, but since most DSLs are fairly simple, FsLex/FsYacc are a perfectly sound choice for use within Visual Studio. And keeping DSLs simple is a good thing, since they are intended to be restricted and simple to learn.
I find Martin Fowler's book to be a good resource, less for the examples and details than as an encyclopedia of DSL ideas. His discussion of useability and other design aspects of DSLs is also worth reading. As Toumas indicated, it does not cover either F# or functional languages. Mr. Fowler writes that he lacked the experience in those subjects to bring the book to market in a timely way.
Having praised FsLex/FsYacc, I do still wish someone would write a good ANTLR back-end for F#. :)
-Neil
I am a fan of embedded DSLs, a la
http://lorgonblog.wordpress.com/2010/04/15/using-vs2010-to-edit-f-source-code-and-a-little-logo-edsl/
http://lorgonblog.wordpress.com/2010/04/16/fun-with-turtle-graphics-in-f/
where you just use leverage F# syntax with some good function names and possibly other syntax cleverness (lists, workflows, ...) to get code that "looks like maybe it is another language" but is actually just F#.
But yes, for external DSLs, you just need a grammar/parser/etc tool chain, and either FsLex/FsYacc, or maybe ANTLR or FParsec are various choices. (I don't have enough experience with any of these to know trade-offs among them.)
Since having made my earlier post, I have also bought and read parts of Terence Parr’s book “Language Implementation Patterns.” It is excellent, though quite a bit more technical than Martin Fowler’s book (with some additional material it could be a “Dragon Book” for the new millennium). The examples are strongly based in Java and ANTLR, but the text is the main thing, so the book is useful regardless of one’s language development environment.
Interestingly, there is little overlap between the two books. Martin Fowler’s book does a good job of covering the design and implementation of basic DSLs, such as those used for specification and configuration, while Terence Parr’s book is more technical and covers the realm extending all the way up through more sophisticated languages and byte-code machines. I recommend both if you can budget for them, otherwise, either is an excellent choice within its given domain.
Martin Fowler has a new book about DSL:s. Sadly, it won't discuss much about Microsoft's tooling nor functional languages.
Microsoft no longer support the graphical tool "Quadrant", but MGrammar is still supported and integrated to SQL server, right? MGrammar is the "DSL making language".
Still, I would say that functional languages (read: F#) are the way to go.
This book has a simple example of how to make a DSL with F#: http://www.manning.com/petricek/
and also Google finds many other good references about this topic.
Try MBase, but it only worth using if your DSL is complicated enough to require an efficient compiler and a PEG grammar. Otherwise FsYacc is more than enough.
Our DMS Software Reengineering Toolkit is designed to handle arbitrary DSLs (I happen to be the architect).
Most people think if you have a parser you have enough, and it is technically true, in the same sense that if you have transistors you can build a computer.
In my experience you want a lot more than just a parser: you need ways to build symbol tables so that your generator knows what the meaning of a particular identifier is, means to analyze the specification, ways to easily encode your translation and to apply optimizations to generated results.
DMS provides all these capabilities to support building DSLs. And in that sense, it goes much beyond F#.
What reading would you recommend on general debugging techniques? I am more interested in principles and best practices than in specific platform solutions. For the record I mainly work with .NET (F#, C#), and dabble in Haskell and Ocaml.
One of these Friday evenings we talked about debugging with my colleague on our walk home. I was surprised to learn that one can view and modify the state of live objects from the VisualStudio debugger. He also mentioned that another developer he knew, a "Java guru," had once shown him some debugging magic and given an article or booklet on debugging, which challenged my colleague's initial "there's nothing to it" attitude. Having spent more time than I wished hunting bugs, I am ready to be challenged as well. Are there any links you would recommend?
I'd recommend reading everything you can find on Test-driven development (TDD). From the Wikipedia article:
Programmers using pure TDD on new
("greenfield") projects report they
only rarely feel the need to invoke a
debugger.
From a personal standpoint, it's been my experience that the more unit tests I write, the less time I spend in the debugger.
Specifically for .NET, here's a nice article on Easier Debugging with Attributes.
I highly recommend the excellent book Debugging by David Agans.
While not specifically about programming, the principles are universal. One of the techniques in here provided the biggest quantum leap in my diagnostic capabilities, namely, backing out your fix to prove that just your fix has corrected the problem.
I've studied a lot of debugging books and thoughts. Probably the best one is Debugging By Thinking. I think it covers everything that needs to be said, in a logical fashion, in an easy-to-read package.
It takes a native approach (win32) but Advanced Windows Debugging is a great book.
I like Ian Taylor's.
Tess Ferrandez's blog If broken it is, fix it you should is both directly relevant to specific real-life scenarios you're likely to encounter in .Net debugging, (typically involving ASP.Net), and more generally thought provoking.
John Robbins' debugging books and blog are similarly worth reading.
Mike Stall's .Net Debugging Blog likewise.
Mark Russinovich's blog is remarkable - his knowledge of Windows internals combined with great forensic skill is impressive.
My first introduction to debugging was this tutorial. It uses GDB to debug a sample C++ code, but the principles are generally applicable. The thing I really like is the way the author explains his train of thought about what might be wrong, and then the specific commands needed to test the possibilities. It's pretty fun! If you're new to debugging, it's a great insight into the process.