Interesting bagofich 1C when working with a managed form context

Never posted on Habr, and here such interesting occasion was drawn.

Issues discussed in the article:

• Choosing publicity or privacy is the question;
• Who is more important - the client or server?
• Read the article and you will see how 1C answers this question in its platform;
• And another unexpected interesting fact about Google will be those who read to the end;
• I will briefly tell you how I found the exact culprit of the bug.

I must say that I am a fan of finding bugs, and bugs love to find me. And the 13th number in my life plays an important role.

Story

So, I sit in the evening (in the courtyard just on December 13), I am working on one of my favorite products xUnitFor1C over a significant release 4.0
')
I test the work of tests in the mode of a managed application when moving from client to server and back.

We have one interesting and difficult scenario of behavior when using server tests in the managed application mode on a thin client.

In the module of the testing core context (Form Control), 2 similar methods were created: Execute Test Method on Client (sign & On Client) and Run Test Method on Server (sign & On Server).
Their purpose is clear from the name.

Usually in the test I used the UprForm method. Perform the Test Method at the Client to check the UV tests, i.e. through the context of the managed form.

All is normal, there are no problems.

But now I needed to check the transition from client to server. I decided that it was enough to use the Run Test Method on the Client, it's time to do a deeper hacking and called the Run Test Method on the Server method.

I wrote a special test, described the behavior according to the script and call EtaForm inside the test. Run the Test Method on the Server.

The test predictably falls, because I work according to the TDD method. I start to figure out what needs to be corrected in the code for the test to work (TDD works that way).

A few minutes pass and I see with great amazement that the method Run by TestTest Method on the Server I call is private, i.e. It has no attribute Export!

At the same time, I successfully call him, and he is doing a great job.

Search and confirmation of the bug in the 1C platform

I do not believe my eyes, because I read a lot of smart books, I know many programming languages, and I understand that you cannot just call a private method.

First I checked, I call the correct code from the right place, etc. After a couple of minutes I was convinced that there was no error, indeed, I call the private method and it successfully works!

I also verified that the Run Test Method method on the Client is a public / export method.

---

According to the bug search techniques, I simplified the situation as much as possible and excluded external factors:

created a separate external processing. Added a simple managed form to it.
Added 2 commands: Calling Private Client Method and Calling Private Server Method
For this form added the following code:

&  () (""); ("  ");  &  () .(); //    !!  &  () ("");  &  () .(); //   ,   ("  ");  

Initially, I ran a similar manual test on the latest version 8.3.7.1805 (released 10/12/2015, if I'm not mistaken).

I get the behavior:

• private server method is successfully called, messages are processed. This is mistake.
• with a private client method is easier. A valid exception is thrown that the method is not found.
  

  {Form.Form.Form (15)}: Object method not found (PrivateAccustomer)
  EtaForm.PrivateNatClient ();

As a result, we get an explicit bug in 8.3.7.

Further, according to the same bug search methods, I check the behavior on another platform 1C 8.2.19
The behavior is absolutely the same.

Checked the behavior on the embedded processing, the same problems.

Actually, the wording of the bug - a third - party code can call the private server method of the managed form through the context of the managed form, and the private client code cannot be called in this way.

---

Rhetorical questions

• It turns out that this is not a bug, this is a feature, because similar “strange” behavior has been observed for a very long time, for several years now?
• But what about privacy / publicity? same basic principles!
• What about encapsulation? it turns out that anyone can call hidden server methods and break behavior.
• But what about equality? Why is the client so disadvantaged compared to the server :)?

As a result, this bug made my evening!

I hope you liked this bugofich.

Wow, now you can turn around to coders in 1C, now you can not write export, everything works without it.
This is how much code you can navigate, if you do not spend time writing Exports! And across the country, what time savings?

But more seriously, I would like to turn to 1C to correct this error.
Peter 1G evangelist , what do you say?
I also propose to build in the product of the APK (Automated Configuration Check) a check for a similar bug.

PS If someone needs, I can give treatment for manual testing.

PPS And if anyone is wondering what's new in version 4.0 of xUnitFor1C , wait for the next article and a New Year's gift!