Phone800.366.3472 SupportGet Support DocumentationDocumentation Resource CenterResource Center
search
close
Open Menu

Synergex Blog


Updated Visual Studio Development Tools Update

By Steve Ives, Posted on March 29, 2021 at 10:44 am

Steve Ives

Synergex is pleased to announce the immediate availability of a new release of the Synergy DBL Integration for Visual Studio, Version 11.1.1g-3045.

As always, this latest release contains improvements across the board, but in particular, the focus was placed on these specific areas:

  • Improving the development experience in both the editing and debugging of .NET Core code.
  • Improvements in working with Repository projects in various scenarios.

Some of the improvements in this release were actually in the Synergy .NET Compiler, so in addition to updating the SDI installation, developers working on .NET Core projects (including any Harmony Core projects) should upgrade the version of the Synergex.SynergyDE.Build NuGet package used in the projects to version 11.1.1070.3045 also.

We encourage everyone undertaking any type of Synergy development in Visual Studio to upgrade to this new release as soon as possible. And remember, if you are not ready to upgrade the runtime versions on your production systems yet, you can use runtime version targeting to give you access to the latest-and-greatest development tools while continuing to support older runtime installations.

Head on over to the Resource Center Downloads page to download the new release now.


CodeGen 5.6.9 Released

By Steve Ives, Posted on March 11, 2021 at 8:10 pm

Steve Ives

We are pleased to announce another release of CodeGen, once again including some significant advances in the technology. We recommend that all developers using CodeGen, and especially developers working with Harmony Core, should upgrade to this latest version as soon as possible. This new version includes these changes and enhancements:


Announcing Synergy/DE 11.1.1g

By Steve Ives, Posted on February 26, 2021 at 3:33 pm

Steve Ives

Synergex is pleased to announce the immediate availability of Synergy/DE 11.1.1g, a quality release that includes a wide range of improvements across the entire Synergy product line. We strongly encourage all Synergy developers to review the release notes for detailed information about everything that changed.

Besides a significant focus on quality, we have also made several feature enhancements in our Visual Studio integration tools, enhancing the developers’ experience and improving their productivity.

First off, we have introduced collapsible-region support for many DBL statements and other language constructs. For example, some of the now collapsible statements include BEGIN-END blocks, USING-ENDUSING, CASE-ENDCASE, IF-THEN-ELSE statements, and more. This feature was specifically requested and voted on by developers in the Synergy Ideas Forum.

We also added support for activating the go-to-definition feature via mouse clicks, in addition to using the existing keyboard shortcut-based mechanism. The default behavior is activated via Ctrl + Left-Click but is customizable in the Tools/Options dialog under Text Editor settings.

Another area that we focused on is improving the accuracy of those “red squiggles” that show up in your code when something is wrong and occasionally when something is not wrong! Inaccurate red squigglies should occur less frequently now, although we do know that have some additional work still to do in this area.

To give developers more options when they need to get in quickly and look at something specific, especially in solutions with large numbers of projects, we also implemented support for Visual Studio 2019’s “Filtered Solution” feature that allows you to check a “Do not load projects” option in the Project Open dialog. Visual Studio opens the solution very quickly when you do this, but all projects are in an unloaded state. The developer can then select the projects they wish to work on in Solution Explorer and use the “Reload Project” context menu to load them. The context menu then includes options to allow you to load either direct dependencies or all dependencies of the projects you loaded, meaning that you can quickly get to a buildable scenario without having all projects loaded. Solution Explorer also has options to show or hide unloaded projects.

Having filtered your solution the way you want it, you can then use the “Save as Solution Filter” context menu to save the state of your solution for the next time you need it that way. The file is saved as a .slnf file and can be reopened the same way you open the solution.

We have overhauled our project build system, reduced memory usage, and improved performance for Visual Studio and command-line builds. And at the same time, we have improved and standardized the way they interact with MSBuild, allowing us to adopt new features more quickly.

And armed with our new MSBuild capabilities, we added support for a new feature known as /graphBuild, making pre-build analysis of inter-project dependencies work much more effectively. In turn, MSBuild can now more effectively perform parallel builds of multiple projects simultaneously, in some situations resulting in improvements in overall build time.

We are confident that most developers should experience improvements in overall build times across the board, particularly for traditional Synergy projects. And in some cases, with the right combination of projects and resources, those improvements could be significant.

For example, suppose you have a small number of base libraries used by a large number of higher-level projects. In that case, once those base libraries have been built, there is a good chance that higher-level projects can build in parallel, with the overall process completing more quickly. The more CPU and memory resources that are available, the faster things can proceed. In some environments, such as on dedicated build servers running CICD pipelines, we have seen improvements of up to 30 – 40% in overall build time as compared to the previously released version. But improvements of that order do require access to considerable resources; most improvements will be more modest.

If you’re already using Visual Studio to develop your Synergy code, we encourage you to upgrade to this new version as soon as possible; remember, you can always use runtime version targeting if you’re not ready to upgrade your production systems. And don’t let the fact that you only develop traditional Synergy code or deploy to Unix, Linux, or OpenVMS deter you; Visual Studio can make a great development environment for those scenarios too! Talk to your Synergex account representative for more information.


CodeGen 5.6.6 Released

By Steve Ives, Posted on February 5, 2021 at 3:05 pm

Steve Ives

A quick post to announce the availability of CodeGen 5.6.6.  This is a quality release that addresses an issue that could occur when generating code from templates containing certain complex expressions. In particular, several Harmony Core templates contain such complex expressions, so we recommend that all Harmony Core developers upgrade to this new version of CodeGen at their earliest convenience. As always, documentation for this new release can be found at https://codegen.synergex.com.


CodeGen 5.6.5 Released

By Steve Ives, Posted on January 24, 2021 at 11:13 pm

Steve Ives

I am pleased to announce the release of a new version of CodeGen, and this release is quite a big one. The changes include the following:

This version of CodeGen was built with Synergy/DE 11.1.1f and requires a minimum of version 10.1.1 to operate.

We recommend that all CodeGen users upgrade to this version, particularly if you are doing Harmony Core development. You can download the new version from GitHub.


SQL Replication Enhancements

By Steve Ives, Posted on December 4, 2020 at 3:21 pm

Steve Ives

For several years now, Synergex has maintained an open-source example that provides an example of how to implement the replication of a Synergy applications data to a Microsoft SQL Server database, in near-to-real-time. The example environment makes considerable use of CodeGen to generate the bulk of the code needed to implement the interaction with the SQL Server database, and much of the remaining required code can be used out-of-the-box, requiring very little, if any change to the original Synergy application to enable the data replication to take place. The example environment has been used as a template by many customers, and our Professional Services team has assisted many others by delivering either proof of concept examples, or full-scale implementations.

As technologies and product capabilities evolve, we periodically revisit the code to ensure that it is taking advantage of the latest features and adhering to best practices. Good performance is also of critical importance in products like this, so we frequently revisit the code looking for opportunities to make improvements in throughput.

We have just completed the latest review of the code, and on this occasion, we did make some changes, which are briefly described below.

  • We now generate an additional function that returns the key number of the first unique key for each ISAM structure. This allows us to avoid the need for code that previously detected the first unique key number at runtime; that code required that the replicator had an open channel to each data file being replicated.
  • We also generate an additional function that, when passed a record containing data, returns the key value of the first unique key. Previously, the code used the Synergy routine %KEYVAL for this purpose, but it also requires that the replicator has an open channel to every data file replicated.
  • Because of the previous two changes, we were able to remove the replicator’s requirement to open the underlying data files that are being replicated. The only files that the replicator now opens are the instruction queue file and log file.
  • We added code to make the replicator more resilient to interruptions to network connections when using xfServer to access the instruction queue file on a remote system. If a network problem is detected, the replicator now closes the instruction queue file and then attempts to re-open it on a new channel. If this operation fails, it will retry several times with a delay between attempts. The number of retries and the delay between retries are both configurable via command-line options or environment variables.

If you already have a SQL Replication environment based on our sample environment, then you might consider checking out the latest version and applying the changes to your own codebase, and if you’d like some help with that, then our Professional Services team will be happy to assist. And if you haven’t yet implemented a SQL Replication environment but are interested in doing so, get in touch with your Synergex account rep and ask them to set up a demo.


Announcing Synergy/DE 11.1.1f

By Steve Ives, Posted on September 22, 2020 at 2:11 pm

Steve Ives

We are pleased to announce the release of Synergy/DE 11.1.1f. This is a quality improvement release available immediately on all Synergy-supported platforms. Please refer to the release notes f0r important information on issues addressed by this release.

Amongst other things, this release addresses several issues relating to running xfServer with encryption enabled. This is a configuration that we highly recommend for all xfServer deployments. If you are doing so and are running an earlier version of Synergy 11, we encourage you to upgrade your server and client systems to 11.1.1f.


Improving Our Internal Development Process

By Steve Ives, Posted on September 21, 2020 at 11:21 am

Steve Ives

We’re about to release another version of Synergy, and when we do you may notice that we’re not documenting any new features in the release. This is an intentional change, and I wanted to let you know about it ahead of time.

In addition to working on Synergy/DE, our development teams are also working on re-organizing many of our internal systems, tools, and practices. We’re centralizing almost all of our development around Microsoft Azure DevOps; we’re consolidating all version control on Git (currently, depending on the product area and platform, we also use PVCS and Subversion), we’re making extensive use of CICD principles and tools to build automated build and test pipelines for all aspects of the product, and much more.

The only exceptions to this are our open source products, CodeGen and Harmony Core, which will remain in their current locations on GitHub. This will be an on-going process extending well into 2021 and, when complete, will put us in a great position to be able to return our focus entirely to Synergy/DE within a modern, highly efficient and productive development environment.

And as part of this reorganization of our environment, tools and practices, we have also made some decisions about how we’re going to release changes to the Synergy/DE products. For the core Synergy/DE runtime products, we have decided to revert to our earlier practice of only releasing quality improvements in patch releases; new features will be released less frequently, in numbered product releases. There are some other changes coming down the pipeline, but we’re still fleshing out some of the details, we’ll let you know as soon as things are firmed up.

This decision applies to the runtime products only, not to the development tools; you will still see regular releases for the Visual Studio-based development tools (and maybe more) in the near future. And development and releases of CodeGen and Harmony Core will continue as normal.


Migration to New Downloads Site Completed

By Steve Ives, Posted on August 14, 2020 at 2:40 pm

Steve Ives

Back in June, I announced the launch of a new product downloads site, which at the time provided access to all of the Synergy 11 downloads, and that downloads for earlier versions would be migrated over the coming months. I am pleased to announce that process is now complete and that the downloads for products all the way back to Synergy 7.1 are now available from the new site and have been removed from the old resource center.

The old download pages also included downloads for the Synergy V6 products but, because the way the software was distributed was so different back then, we decided not to migrate those old versions to the new site. For now, the version 6 files can still be downloaded from the old resource center, and we will make those files available via some alternate mechanism before that site is eventually decommissioned.


Announcing Synergy/DE 11.1.1e

By Steve Ives, Posted on July 14, 2020 at 2:04 pm

Steve Ives

Due to the discovery of a potentially serious issue in the 11.1.1d release of Synergy/DE, we have decided to withdraw that release on Windows and UNIX platforms and replace it with 11.1.1e, which is now available.

To understand the issue, it is first necessary to understand that enabling compression on a data file can, in rare cases, result in a small increase in the size of some records! This can only occur if the data in a record is not compressible, yet the compression itself adds a small overhead.

It was found that when reading records from a compressed file, by RFA, any records exhibiting this “negative compression” would have one byte of bad data returned at the end of the record.

11.1.1e includes new versions of Synergy/DE 32-bit and 64-bit for Windows and Unix platforms, and Synergy DBL Integration for Visual Studio (build #2769).

We strongly recommend that anyone who has updated to Synergy/DE 11.1.1d on the affected platforms should immediately upgrade to 11.1.1e.

As we needed to release a new version to address the READ by RFA issue, we decided to also include several other quality improvements that had already been completed.

Synergy/DE Runtime

(Windows) In 11.1.1d, when using SYN_RESIZE_SCALE or having a monitor DPI change, some .NET controls would fail to repaint if the application moved between monitors of different DPI or scaling.

Traditional Synergy Compiler

A global structure with the same name as a subroutine no longer causes a segmentation fault when loading prototype files when there are different prototype files for the global structure and the subroutine.

Synergy Configuration Program

We addressed an issue in rsynd that was causing the SynConfig utility to fail with a “Could not complete services import” error when specifying a user account during service import.

Synergy DBMS

We enhanced the isutl utility when recovering change tracking files with bad change tracking links, and the utility no longer crashes if certain wildcard file operations are attempted.

Visual Studio Build System

We fixed an issue in the incremental build feature in SDI 11.1.1d-2749 through 11.1.1d-2763 that caused full project builds to occur when only partial builds were necessary for projects using common.props and with non-Synergy references.

We fixed an issue that prevented low-level libraries in Synergy .NET Core solutions from automatically rebuilding when an output file was missing.

Visual Studio Property Pages

We fixed an issue that prevented Visual Studio settings imported from a file from working until a Synergy DBL option page (Tools > Options > Text Editor > Synergy DBL > …) was opened.

We fixed an issue with Synergy .NET Core and .NET Standard projects that prevented SDI from resolving known MSBuild properties used for pre-build and post-build events.

For additional information and tracker numbers associated with each of these items, please refer to the release notes.


Announcing SDI 11.1.1d-2763

By Steve Ives, Posted on July 2, 2020 at 1:01 pm

Steve Ives

Shortly after the recent release of SDI build 2755 we discovered an issue that we wanted to address as soon as possible, so today we are announcing the release of build 2763, which we recommend for everyone using Visual Studio for Synergy development.

We are not aware of any customers being affected by the issue, and we have removed the download link for the previous build.

For additional information please refer to the release notes.


No More SDI “Developer” Builds – Just Releases

By Steve Ives, Posted on June 29, 2020 at 3:12 pm

Steve Ives

I wanted to make you aware of a small change that we have recently made to the way that we refer to “interim” releases of the SDI (Synergy DBL Integration for Visual Studio) product.

A few years ago, it became clear that we needed to be able to release our Visual Studio Integration tools on a more frequent cadence than the main Synergy/DE product. So we started doing interim releases that we referred to as “Developer Builds.” Each developer build was identified both by a version number and a build number.

Initially, these builds were often not subject to the same levels of stringent testing that a build for a full release would be, and we made that clear to customers. But now, thanks to considerable improvements in our automated testing processes, these interim builds are now subject to the same levels of inspection and testing as a build for a full release, and it is no longer necessary to discriminate between developer- and full-builds.

For this reason, we have decided to stop referring to these releases as “Developer Builds,” they are now all just “SDI Releases,” which will continue to occur on a much more frequent cadence than Synergy/DE.



xfBBQ: Full-Stack Web Development with Harmony Core

By Steve Ives, Posted on June 15, 2020 at 9:00 am

Steve Ives

On Thursday, June 18th we will launch a new series of webinars called the xfBBQ Webinars, and I’m guessing this may require some explanation. So here goes:

What is xfBBQ?
xfBBQ is a browser-based application, designed and created by Johnson Luong, Synergex Software Developer, (with minor input from Jeff Greene, Harmony Core Technical Lead, and Synergex Principal Engineer) to help us plan for our regular company BBQs. The ones that we are NOT currently enjoying because of the COVID-19 pandemic! Generally though, we host around six BBQs outside our office at lunchtime during the summer season, but most of you won’t care about that because you’re not invited 😉!

Who is Johnson Luong?
Johnson is a valuable member of our development team who, since joining Synergex in 2014, has worked on many different parts of the Synergy/DE toolset. Recently he has played a major role in the creation of our Windows installations using the WiX Toolset, while at the same time having made significant personal contributions to the development of the entire Harmony Core framework.

What does xfBBQ do?
The app allows customers (employees) to register for access, then informs them when BBQs are scheduled, and allows them to select from, and customize, various menu selections for each BBQ. For example, for a given BBQ, I might use the app to express my preference for a “medium rare cheeseburger with hot peppers and a well-done dog.” I could even opt for two burgers, or two dogs, or both … but in doing so I may risk the wrath of Samantha, our wellness coordinator! Johnson assures me she doesn’t have a special “back door” into the data, but I’m not convinced!

Anyhoo, the app collates the orders, presenting the BBQ officials (all who lavish in Synergex VIP status, and rightly so) with the required lists of requirements and ingredients for each BBQ event. Yada, yada, yada.

Why did we do this?
Because having developed an awesome (our words, but we’re confident) web-services framework called Harmony Core, customers were asking for real-world examples of how it might be used. And … we had a real-world problem to solve, namely that we really needed to control the amount of burger patties and sausages that we were purchasing from Costco!

Why xf?
Just for fun! Johnson believes that he has now defined the actual meaning of “xf”, but trust me, he has no clue! Until it’s been ratified by Marketing it means nothing, and that process could take years!

But seriously, this webinar series presents to you an end-to-end view of how a modern browser-based application is developed. You will see how the Harmony Core back-end is built, but you have seen that in previous webinars. What is much more important here is the focus on the development of the front-end application that interacts with the Harmony Core service.

This will be a series of four webinars, as follows:

Thursday June 18 @ 9 am PDT
Creating a Harmony Core solution and hooking it up to a new React app.
Register for part one here.

Thursday June 25 @ 9 am PDT
POSTing data in React, and an introduction to Redux.
Register for part two here.

Wednesday July 1@ 9 am PDT
Captchas, batch processing, and other CRUD.
Register for part three here.

Wednesday July 8@ 9 am PDT
User authentication, styling with Bootstrap, and making a React production build.
Register for part four here.

xfBBQ is a browser-based app. It is a single page application, developed using React and Redux, and using appropriate sprinkles of HTML and JavaScript along the way.

We are completely excited that over the last few months we have built up a marvelous following for our Harmony Core webinars, but I’ll be honest, there won’t be much DBL code to see here! Regardless, I encourage all of you to join us for this webinar series, and to stick with it to the end.

If you’re a DBL dev you may not learn much about your own part of the puzzle that is building a modern distributed application. But I promise you, by the end of the process you will have learned a lot about what it takes to pull together all the other pieces of that puzzle. Building a modern, distributed application requires skills in many different areas, and this webinar series touches on many of them.

It is most important that we get your non-Synergy developers to participate in these webinars. Your web devs will be right at home here, but if you don’t have web devs then invite your Windows devs, your iOS and Android devs, and your MacOS devs.

Web services are accessed via HTTP, and pretty much every development language can do that! The perfect target audience for these webinars is anyone that is involved in developing your next-generation apps. It’s not about any one part of the process, it’s about the entire process, end-to-end, and that will require devs with many different skill sets get together, and to work together to create success!


Unit Testing in Traditional Synergy

By Steve Ives, Posted on June 12, 2020 at 9:00 am

Steve Ives

One of the most significant new features introduced in Synergy/DE 11.1.1d is a unit testing framework for traditional Synergy. The framework is based on the MSTest framework that we have supported in Synergy .NET for some time and is delivered as a component of our Synergy DBL Integration for Visual Studio product.

Introduction

Unit testing is a method of testing software at a low level, usually at the level of individual subroutines, functions, and methods. Unit tests are frequently written by the same software developers that write the code being tested, and sometimes, in the case of test-driven development, even before the actual code being tested.

The idea is to exercise each routine in as many different scenarios as you can think of, passing various combinations of parameters, both correct and incorrect, and perhaps by altering the execution environment. The goal is to prove that the routine responds correctly in all cases when used correctly, and also to prove that it fails appropriately in all cases when it should fail.

Unit tests are generally small and fast to run individually, but numerous. It is not uncommon to have hundreds or even thousands of unit tests, and, ideally, those tests execute quickly enough to make it feasible to run them frequently.

In some environments, unit tests are configured to run each time the developer builds a new version. In other environments, tests might run as part of a “continuous integration / continuous deployment (CI/CD) pipeline that runs each time developers attempt to check code into a central repository, and the failure of a unit test might cause the check-in of the code to fail.

Adding Unit Tests to a Solution

To make adding unit tests easy, we have provided a new Visual Studio project template named “Unit Test (Traditional).” It adds a traditional Synergy ELB project to your solution, and that project contains some sample unit test code.

Adding Test Classes and Test Methods

Unit test projects contain unit test classes, and a unit test class is simply a class that is decorated with a {TestClass} attribute. Here is an example:

Unit Test Class

A unit test project can include any number of unit test classes. Generally, a test class groups together a related set of tests. In the case of the code above, notice the name of the class is CustomerApiTests. Presumably, tests that exercise a Customer API are to be added later.

Each test class contains one or more test methods, which are, once again, decorated with an attribute. In this case the {TestMetod} attribute. Here is an example of a test class containing several test methods:

Unit Test Methods

The code above declares three test methods, each of which tests a particular piece of functionality of the API. But this is just a simple example. In an actual test class, there may be several test methods to test each of the API functions in different ways. The number of test methods per function is typically determined by how complicated the function is, how many parameters it has, how many different things it can do based on those parameters, etc.

Coding Test Methods

Each test method typically contains a small amount of code, sufficient to test a particular scenario. The operating environment must be the same each time a particular test runs; we’ll talk more about that later. Here is an example of a test method that contains some simple code.

Unit Test Code Example

When writing unit tests, many developers follow what is known as the “AAA Pattern,” which stands for “Arrange, Act and Assert.” First, you arrange (or prepare) whatever is needed to execute the test, then you “Act” by executing the test, and finally, you “Assert” the result of the test. The name of this final phase is interesting because, in MSTest, Assert is the name of the actual class used to notify the framework of the results of a test.

In the example above, the arrange phase involves creating a new instance of the CustomerAPI to use for the test. The Act phase then uses that object to make a call to the API function to be tested. And in the Assert phase, the code checks that the expected customer record was returned.

The Assert Class

The Assert class has many different static methods used to signal success or failure based on various scenarios. The method you choose to use depends on the nature of the tests that you need to execute to determine the success or failure of the test. Some examples of Assert methods are:

Assert.AreEqual(expectedObj, actualObj)
Assert.AreNotEqual(notExpectedObj, actualObj)
Assert.AreSame(expectedObj, actualObj)
Assert.AreNotSame(notExpectedObj, actualObj)
Assert.Fail()
Assert.Inconclusive()
Assert.IsTrue(condition)
Assert.IsFalse(condition)
Assert.IsNull(object)
Assert.IsNotNull(object)

Most of these methods also have several overloads with different combinations of parameters. For example, most also have a variant that allows an error message to be recorded in the case of a failing test, and more. In traditional Synergy, the Assert class is located in the Synergex.TestFramework namespace, along with the various attributes mentioned earlier.

By the way, I should mention that if any test method fails with an error, or throws an exception, then the test framework catches those errors and exceptions and reports them as test failures in the Test Explorer window.

Building Tests

When you build a solution that includes a unit test project, that project builds just like any other traditional Synergy ELB. It is likely that the code being tested by your unit tests exists in one or more other projects in your solution, so to give your unit tests access to that code, you simply add references to the other projects. Also, if you are using a Synergy repository project, and your unit tests require repository data definitions, then also add a reference to the repository project in the usual way. And like other Synergy projects in Visual Studio, if your development environment and code rely on the values of environment variables that are defined using the “Common Properties” method, you may need to opt- into those common properties via the project properties dialog in the usual way.

The Test Explorer Window

Visual Studio includes a piece of UI called the Test Explorer. If you don’t see it already displayed, you can display it by using the menu commands Test> Test Explorer.

Empty Test Explorer

When the Test Explorer window it first displayed, it often starts out empty, but notice the instructions that are displayed in the window, which says, “Build your solution to discover available tests.”

Once you build a project that contains unit test classes and methods, the Test Explorer window will discover and display your tests:

Discovered Tests

By default, your tests are displayed in a hierarchy based on your project name, namespace, and class, and then the individual methods are displayed below each class.

Notice the two green buttons to the left side of the Test Explorer toolbar. These are the Run All Tests and Run Test buttons. In my sample scenario, only one of the tests contains any code; the other two test methods are configured to throw an exception that says “Not implemented.” Here’s what happens when the Run All button is clicked:

Test Results

As you can see, Test Explorer is presenting a summary of what happened when it attempted to run each of the three methods. One test passed, and two failed. Notice the color-coded icons, green is good, red is bad, and notice that all of the parent folders are also red. For a parent folder to show a green icon, all tests below must pass.

Also, notice how the Group Summary pane is displaying a summary of the pass/fail information. This is because we have a folder node selected in the tree. If we select an individual test, then the pane displays the details of the result of that specific test:

Individual Test Results

In addition to executing all tests or a single test, you can also select a number of tests, and use the right-click menu to execute just that set of tests:

Selected Tests Run

In the above screenshot, you can see that the third test was not executed, which is indicated by the light color of its icons background.

Debugging Tests and Tested Code

In addition to merely running tests, it is also possible to use the Test Explorer to launch debugging sessions for specific tests. To do so, right-click on the test and select Debug. A debugger session will start, and the debugger will break in the test method. You can debug the test method, and as long as you have the source code available, you can also step through into the underlying code being tested.

Organizing Tests

As the number of tests in your environment grows, it is likely that the sorting and filtering methods provided by the Test Explorer may not be enough to allow you to work efficiently. For this reason, it is also possible for you to apply custom categorizations to your tests in code.

This is done by decorating your test methods with an additional attribute named {TestCategory}. Here is an example:

Categorizing Test Methods

And having done so, there are options in the Test Explorer toolbar to modify the display hierarchy to include “Traits,” which are the custom attributes that you have applied to your test methods. Here is an example of that:

Test Explorer Traits View

Environment Initialization and Cleanup

As you start to really get into writing unit tests, you will quickly realize that a big part of the road to success lies with your ability to always run your tests in a consistent and known state. For example, if your tests are reading and writing data files, those data files need to be in a known good state.

To help with that, the framework provides some special functionality that can be used to establish and reset the environment, if necessary. In MSTest, there are six such mechanisms; in traditional Synergy, we currently support four of them. These are:

  • ClassInitialize – runs once, BEFORE any test in the class runs
  • TestInitialize – runs BEFORE EVERY TEST in the class
  • TestCleanup – runs AFTER EVERY TEST in the class
  • ClassCleanup – runs once, AFTER all tests have completed

You can optionally add methods to your test class to provide each of the functions that you require. To do so, you simply add public void methods, decorated with an appropriate attribute, like this:

Special Test Class Methods

For example, if you are testing an API, and that API is completely stateless, then instead of creating an instance of the API in each method, then using it and discarding it, you could use a ClassInitialize method to create an instance of the API, code all of your test methods to use that same instance, then delete the instance in the ClassCleanup method.

If your API is not stateless and you do require a new instance for each test, you could simplify the code in each test by defining the code to instantiate the API in a TestInitialize method and discard it in a TestCleanup method. The runtime overhead is the same, but you only have to code the APU creation one time instead of potentially hundreds of times.

In MSTest, there is a third level of Initialization and Cleanup that happens at the “Assembly” (ELB in this case) level. This is implemented the exact same way, via the attributes {AssemblyInitialize} and {AssemblyCleanup}. We do plan to add that support; it just didn’t make it into the initial release.

Summing Up

This post is not intended to be a complete guide to the subject of unit testing in Traditional Synergy, and indeed there are other features that have not been discussed here. Instead, the intention was to provide enough information to pique your interest, and hopefully, that goal was achieved.

I encourage you to refer to the Synergy documentation for additional information, and we are looking forward to receiving your feedback on this important new technology for traditional Synergy.


Don't miss a post!

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Recent Posts Categories Tag Cloud Archives