Yesterday MS launched Getting Ready for Microsoft Dynamics NAV ‘7’ on PartnerSource listing "... planned resources to help you get ready for Microsoft Dynamics NAV ‘7’."
If you have access to PartnerSource go there and inform yourself. Not yet all-the-things-that-you-maybe-would-like-to-find are there, but it's a good start and a good list of reasons why you should go to Directions EMEA 2012 in Rome. The page will be updated so "... check back soon for the latest available resources and continue to check back often at this site for the latest updates."
For those who still do not know enough about me: http://www.dynamicsworld.co.uk/interview-luc-van-vugt/
Ouch, keep on singing the RED/GREEN/REFACTOR mantra wasn't that easy the last couple of weeks preparing myself on my NAV Development with Team Foundation Server presentation. But that's past now and I can look forward again. I can go ahead again. Nothing to stop me from getting to GREEN ...
Nothing? Really no thing?
Well, there is one thing I should tackle first as I got a bit mixed-up in my previous TDD post. You know, I wanted to bring in the C/AL statement ASSERTERROR and at the same didn't want to fuzz too much about the missing requirement. I wanted to keep that for a later elaboration.
Although it wasn't really a bad thing, it just wasn't neat and maybe a bit confusing. I could have known then, if I had read the following sentence with a little bit more mindfulness:
The ASSERTERROR keyword specifies that an error is expected at run time in the statement that follows the ASSERTERROR keyword.
So what am I hinting at?
I introduced ASSERTERROR as a means of inverting the result of the Assert.IsTrue statement and it exactly did what I wanted it to do: turn the result from FAILURE to SUCCESS. And indeed the Assert.IsTrue statement is throwing an error. Just have a look in codeunit 130000 (Assert) and see what happens if Condition is false:
IsTrue(Condition : Boolean;Msg : Text[1024])
IF NOT Condition THEN ERROR(IsTrueFailedMsg,Msg)
But this whole Assert codeunit (and the functions it contains) is part of our test framework, and even though its code might throw errors, it doesn't make real sense to test that; in other words: it doesn't make sense to test the test framework. Typically we rather apply ASSERTERROR where it concerns testing the product (code). And we have a perfect alternative available in the same Assert codeunit (130000): IsFalse.
Thus our FailingVerification test function would become:
FailingVerification()
// Create a purchase headerPurchHeader."Doc. Amount" := 2.5; //Mimic an incorrect manual input of the total doc. amount PurchHeader.INSERT(TRUE);
// Create two purchase lines to the headerCreatePurchLine(PurchHeader."No.",10000,1);CreatePurchLine(PurchHeader."No.",20000,2);
//Check if manually entered total doc. amount does not equal the line amountsAssert.IsFalse(PurchHeader.VerifyDocAmount,'Verify Doc. Amount')
Well, we touched our test code so let's see that it's still working OK. Cross your fingers and ... (6) run test and see it pass:
OK! Do I need to phrase out loud the color?
Way back late summer 2009. Almost a year ago NAV 2009 was out of our hands, NAV 2009 SP1 was at the verge of being pushed into the world and I ... just one month ago the MS doors were closed behind me and I made my steps into the partner world picking up my new job at Imtech ICT Dynamics Solutions as Technical Consultant, which became more and more Product Manager.
Imtech ICT DS, a typical NAV partner having a drive for their customers doing all of their NAV development in various CSIDE databases. Except for copy/pasting databases there was no advanced way of securing the code, let alone more sophisticated tools to support efficient propagation of fixes and features from one code source to another. I reckon you can make an intelligent guess at the answer I did get to my question what kind of source control system (SCS) was being used. So that's were my quest started which more or less came to a conclusion last Monday with my presentation "NAV Development with Team Foundation Server" at the Dutch Dynamics Community event in Arnhem. A retrospective of the whole process.
Now with this post I will lift it to the next level. Share our experiences with a much wider audience. Bringing Dynamics and Classic MS closer? Hopefully. Helping to prepare for the next steps in your profession? Exposing myself to your feedback. Revealing myself ... do I dare to say it ... do I ... as an ... expert on this matter. Offering my services as freelancer where you get stuck.
So why did I wanted us to move to a SCS (in question form)?
With these questions and prerequisites I started my investigation, bringing me to the DevDays in 2010. Talking to various experts. Having a very close look at Perforce. A real very close look as this was exactly what I was looking for in terms of SCS having flexible branch definitions (which TFS still is missing) and cool ... yeah really cool graphical tools. But missing the sheer fact that it was not part of the MS stack and that TFS is maturing and indeed made a huge leap forward with Visual Studio 2010 in terms of becoming, no being, a complete Application Lifecycle Management (ALM) tool. Brian Keller, Matthew Mitrik and Gerard van der Pol (MS) did a good job in getting our nuts and bolts together for VS 2010 and giving some sneak previews into VS vNext.
And then, not in the least important: slowly but gradually tools are becoming available to bridge the gap between TFS and NAV:
Hence we decided to get on with TFS as our SCS, and ALM, tool. But we had to deal with some inflexibilities of TFS and setting up a fitting branching strategy.
We'll dive into these in some future post.
Feel free and download my DDC pdf-ed powerpoint here.
If you are considering to buy a PACKT book on Dynamics go out there and take profit of their discount during February.