Back in Ye Olden Times when I went to college, object-oriented programming was barely starting to become a thing. It didn’t help matters that the particular school I went to was behind the times on its computer science program, either. So I didn’t discover until I was actually in the workforce that of all the languages I’d learned about in college, the only one that was at all useful was C.
C# hadn’t been invented yet when I graduated. When I look it up, I see that Microsoft put out the first release of C# around 2000 (source: Wikipedia’s C# page), and by then, I was working at Attachmate. Attachmate was one of the last times I had any opportunity to work with C++, aside from one short contract I had after they laid me off.
Up till then, my only work at Microsoft (my full-time stint there in the early 90’s, and my contract work in the mid-90’s), was pre-C#. My next work at Microsoft, the two back-to-back contracts I had from 2003 to 2005, was straight up testing: a mix of manual testing and running automation written by the team’s actual employees. I didn’t have any opportunity to work with any language directly myself, much less C#.
After that, all of the full time gigs I’ve had were ones functioning outside the Microsoft-based ecosystem. Big Fish in particular was a Python and Java environment. Which has been great for my accrual of Java and Python experience!
But now that I’m back on the job market, I’m seeing regular signs of jobs asking for C# coming across my radar. So far, I’ve had to tell recruiters that I don’t have any professional experience working with the language, or for that matter with modern versions of Visual Studio. (The last time I would have seen any version of Visual Studio would have been that aforementioned short contract. According to my old resumes, round about then, I was mentioning working with Visual Studio 6.0 and Visual Studio .NET.)
I figured, though, that as long as I have time on my hands it would behoove me to try to actually get some hands-on experience with the current release of Visual Studio and with C#. And, since I’ve been told by former Big Fish colleagues that C# is very, very similar to Java overall, I figured I’d try to port my current Java work up on Github over into C#.
As of this writing, I have done this! The code I’ve ported so far is the little test suite that runs the REST API tests against my test WordPress site. This ported code now lives on my Github in its own repo.
Things I have learned from this experience
I do not like Visual Studio as much as I do IntelliJ for an IDE. But since part of this entire point was to practice getting hands-on experience with a current Visual Studio version, I put up with that. And it helped that I figured out a few ways to make Visual Studio less cluttered, by docking the things I need access to off on the side to be hidden until I need them. That frees up most of the screen on my dev laptop for me to see my code.
C# is, indeed, a LOT like Java. It’s simultaneously enough like Java and enough different from Java that the little differences will probably catch me up a lot if I wind up regularly working with this language. Nothing I couldn’t eventually get used to. But it’ll be a thing I’ll need to look out for.
I don’t like that Visual Studio makes me have to re-add a file in git every time I change it. (IntelliJ does not make me do this, even on Windows.) When I went googling about this, I found that this is apparently by design.
I do like the concept of a “namespace” that’s apparently a thing in C#. If I understand it correctly, the idea here is to have a big set of associated files. This seems to simplify matters a bit, and has saved me having to do a few extra import statements.
Oh wait, I’m sorry, not “import”. “Using”. See previous commentary re: differences between C# and Java.
Something else I’m still having to get used to, and this is a question of “quirks of the IDE” as opposed to “quirks of the language”: if I want to run tests in Visual Studio, I have to hit the Test Explorer for that. I can’t build the project directly, otherwise it’ll complain at me. This seems to be because I’ve built my various test classes as class libraries, as per various tutorials I’ve seen on how to set up tests. Which means in turn that Visual Studio won’t let me run them directly. Apparently you only get to run things in Visual Studio if you’re specifically building executables?
Lastly, a quibble of terminology: I don’t like that Visual Studio calls its projects “solutions”. It’s a bit too rah-rah YAY GO SOLVE YOUR PROBLEM for me. And I’m all “yes yes I’m going to STOP TRYING TOO HARD TO HELP ME”, here.
Which, I feel, exemplifies my experience with Microsoft products overall rather well.
Specific libraries I’ve discovered
A lot of this porting work has been “learn how to deal with the language” as well as “learn how to deal with the IDE”. But there’s also been some measure of “find C# equivalents of the technology I’m used to dealing with in Java”. One of these has been TestNG. The recommended C# version of this is apparently NUnit, which seems fine so far. Learning how to deal with this has been just a question of learning its specific syntax for annotating test methods.
Likewise, the current recommended way of doing REST API testing in C# seems to be RestSharp. From what I saw in my googling, apparently there’s now an in-language way of doing this, but I stuck with RestSharp as it seemed a good analog of the Unirest library I learned how to use on the Java side.
Lastly, since I needed to find an equivalent for how Java parses JSON, I went with LINQ to JSON in the JSON.NET/Newtonsoft library. This has been a pretty close match to the json.org libraries you can use in Java, and gives me the same level of ability to parse JSON payloads without having to worry about deserializing them.
(Which took me a bit of work to discover. RestSharp’s docs seemed to really really REALLY want me to deserialize JSON I get back on REST API calls. This is not helpful if all I really want to do is look into the JSON and go “yes, I see the correct value(s) in there”, as opposed to actually saving the stuff out into variables and doing additional things with it.)
What’s next
I also want to port the Selenium-based tests into C#. But since the Java version of these tests specifically uses Selenide as a framework to do its testing, I want to find a C# library that does the same thing. Atata seems promising and I shall investigate it.
Tutorials I’ve found so far for how to do Selenium-based testing in C# talk a lot about how to install Selenium and browser drivers into your Visual Studio. I don’t actually need to do that, given that I already have a Docker grid running. And since I already know how Selenium works, all I really need to know is how to get my C# code pointed at a Selenium grid.
Job descriptions that come across my radar also keep periodically mentioning Cucumber. This is a thing I discovered during my last research project at Big Fish, so I’ve been a bit interested in checking it out. I don’t know yet how well it plays with C#. This may also require investigation.
All in all
This has been a valuable experience so far. I can now say with assurance that if called upon to do so, I can in fact deal with both C# and Visual Studio.
Under no circumstances can I be called an expert, mind you. And I would still not be a good job match for any position that requires multiple years of experience working in the C# realm. But for any position with a bit more flexibility, where they’d be willing to go “oh sure, you have experience with Java and Python and have at least SEEN C#? We can work with this”? I could do that.
Also: given that I’m an amateur musician, I do have to say, I do like that the language is called C#. I play that note a lot on my fiddle and on my winds. I’ll take any little connection to music in this endeavor that I can get. :D
