Unit testing - can I use the Acumatica sample data in SQL server?

@Dmitrii Naumov  THANK GOD.  The graphs in my application are complex and I don’t think there is a single case where a unit test could be applied.  To test anything, I need a full database. 

I’m very excited to look into Test SDK!  I will do some web scrounging on it.  I hate to be one of those people who don’t do any homework before asking.

Thanks for the quick reply so I know to stop beating down the doors on Unit Testing.

@Dmitrii Naumov  and @AaronB, I found your github and I found a great walkthrough here: https://www.acumatica.com/blog/creating-acumatica-test-sdk-tests-from-scratch-for-isvs/

Got a lot of learning to do.  Lucky it is a long weekend!  :-)  Thanks again.

Hi @Joe Schmucker 
I'm sure you found you should use salesdemo as the base if your testing.

That blog post you link is quite out dated now, although it may still work, we have done significant work to make things easier and its all contained inside this git project now.

https://github.com/Acumatica/Test-SDK-Starter-Guide

In addition there are guides on how to use Customization Plug-In to enter data into Acumatica using a customization project.
Another option is if you can prepare SQL scripts, you can use C# code to connect to the database and execute SQL statements inside the test.

Thanks @AaronB .  I was using the blog post to “get started”.  It has been really helpful.  I also have your git code open in another vs instance so I can use that as a reference.

I’ve finally gotten to the place where I can generate the “wrappers”.  I’m at the procrastination stage now as I am a little mortified of the next steps.  😉

Since my application is for merging customers and vendors, I touch pretty much everything in the DB.  All my development and testing has been using the sample data.  It is an absolute necessity.  Unit testing is pretty much not going to work for me.  Hence, following your lead on this using the test SDK.  

I am grateful you took the time to put together the git project and your blog.  I’d not be able to do any of this without it.

To keep all ISV tests in a generally standardized format - We strongly recommend taking the git code, and renaming the solution to “SolutionNameTestSDK” and deleting all unnecessary example code. This ensures you are using the correct project type, .net version, etc. Note: you will have to open the .sln in a text editor to update it fully. 

Once you get the folders set up according to my most recent updates in the readme.md - getting the project to generate wrappers and run the sample tests takes 5-30 mins following exactly the steps in the readme.

If you have an ADN L2 subscription you can create a support ticket to our team and I can walk you or anyone else through the process.

It’s not uncommon to need to refactor your code to support unit testing. Generally speaking even complex code should be able to be broken down into less complex parts that can be tested individually.

Every project is different but unit tests are usually the easiest to write and fastest to execute.

@markusray17  I understand.  However, my custom screens require access to many tables in Acumatica which must have data.  I would have to populate over 100 tables with data.  I have been advised to use TestSDK for my testing.  My application is a merge utility for merging customers and vendors.  You can imagine how many tables that touches.

I don’t think Dimitrii’s advice wasn’t that you should use TestSDK over unit testing but rather that the type of testing you are trying to do was a better fit for TestSDK. A standard testing strategy would involve both unit testing and TestSDK(or similar tools).

With unit tests you wouldn’t be testing the entire application or the top level functionality. In your example you would be testing something like the logic to resolve a conflict with different descriptions on the customer/vendor records. To test that, all you would need to feed the method is the conflicting descriptions. 

@markusray17 I got it.  I have never done unit testing and after watching the tutorial and playing around with it, it looks like in order to unit test whether the From Customer Number is the same as the To Customer Number in my screen, I need to reference my graph.  The From and To customer numbers are lookups in the DAC with joins.  I would think that if there isn’t data in the tables that are part of that lookup, accessing graph fields to test if the FROM and TO are the same (which would be an error I test for in my code) would throw an error.

In the sample unit testing video, the instructor had to insert data into every table that was involved in the test.  He had to insert key field values in the tables.  To insert a record into the customer table, I need a BAccount record which is also part of the join on the From and To customer ID fields.  To have a BAccount record, I need a BOAT load of other tables to have records.

Are you saying that in Unit Testing, I don’t need to comply with the DAC required fields/constraints etc.?

Not exactly, what I’m saying is that the “unit” you test is up to you. Many of the samples that Acumatica shows are testing methods/event handlers/actions that would require interaction with the cache/graph but that doesn’t have to be the case.

In your example, you likely don’t really need to test the selection of the data from database/cache. It sounds like what you want to test is that if the From Customer Number and the To Customer Number are the same the application throws an error. If you extract that logic into a method all that method would need is the From Customer Number and the To Customer Number. Once you have extracted that logic you can easily test it by calling the method twice in your tests and passing  customer numbers that are the same the first time and different the second time(and expecting an error to be thrown the first time but not the second time). 

Essentially unit testing only needs the data that a specific unit of logic(that you are trying to test) directly depends upon. That is where refactoring your code comes in, to isolate that specific logic you want to test with it’s specific dependencies(typically in the form of a single method or class).

@markusray17 I understand what you are saying.  I will take another dive into it.  My ignorance here is to blame.  Thanks for taking the time to write that info for me.  I really appreciate it!