Test Case Version numbers? Test case creation within existing libraries?

Help Test Suite
1

I’m in the process of creating test cases for our in-house libraries, and I’ve added the ‘UiPath.Testing.Activities’ dependency to the already built library.

  1. What is considered best practice as to whether test cases should be part of a standalone ‘Test Automation’ project, or is it fine to build test cases directly in the libraries? I’m planning to run these test cases on a schedule within our on-premise Orchestrator.

  2. How is the version number defined when publishing a test case? For example, the existing library has a version number of 1.0.4, and prior to publishing a test case any updates would increment by 0.0.1. After publishing a test case the naming convention is ‘1.0.143639940’. I haven’t been able to find what this convention relates to, though in testing I saw that it relates to date and time somehow.

Thanks!

1 Like
2

@Alex76

  1. It would be better to have your test cases along with library as you would test the activities directly there itself and no separate imports are required when libraries are upgraded…easy for maintainance
  2. The versioning can be given as per your convinience …you can edit the version number while publishing as you need per the requirement

Cheers

3

Thank you for your feedback @Anil_G!

  1. The versioning can be given as per your convinience …you can edit the version number while publishing as you need per the requirement

  1. I understand it can be changed manually, however even if I change it back to the regular convention (i.e. 1.0.4 and so on), if I publish another test case, the version number is hijacked with the odd format again (i.e. ‘1.0.143639940’). So, if I want to maintain the versioning, I’ll have to keep track of version numbers manually every time after I publish a test case.

  2. I also don’t understand how this convention makes sense logically? Do the numbers represent anything if broken down into parts?

4

@Alex76

  1. When publishing the project you will also see the current version …you just need to add plus 1 to it. No need to check somewhere else
  2. It is some unique identifier for it…but I dont think any specific significance

cheers

5

Thanks @Anil_G - I marked you as solution for the test case question, as it does make sense to have test cases within the project to avoid having to handle two separate projects with their own dependencies.

After some testing… the version numbers do have a relation to date and time as mentioned. I just didn’t figure out the exact pattern.

For example here’s a series of date and time and version numbers taken as close as possible the mentioned date and time…

7/20/2023 - 4:20:00PM → 1.0.143579942
7/20/2023 - 4:20:30PM → 1.0.143579971 (last two digits increased by 29… closely matching the time elapsed)
7/20/2023 - 4:21:00PM → 1.0.143580002

7/21/2023 - 8:45AM → 1.0.143639101

7/24/2023 - 10:38AM → 1.0.143908682

Also, the bolded numbers in the minor version number (i.e. ‘5’, ‘6’, 9’) match the amount of days that passed.

To be clear, this is more of a curiosity for me at this point, but it would still be great to understand how this version number is generated.

6

@Alex76

Looks like the epoch date to me

Cheers

7

@Anil_G

“Looks like the epoch date to me”

I thought of that, but unfortunately it doesn’t match:

image

Current version 7/27/2023 9:39AM
image

Maybe some sort of custom epoch date though for sure… :slight_smile:

1 Like
8

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.