search

keenlabs / keen-sdk-net

A .NET SDK for the Keen IO API
MIT License
37 stars 24 forks source link

Added .Net Standard Class Library #97

Closed Pothulapati closed 6 years ago

Pothulapati commented 6 years ago

Closes #60 @masojus I've added the following files(which didn't have many dependencies) to the .Net Standard Class Library.

Keen.NetStandard/CachedEvent.cs Keen.NetStandard/DynamicPropertyValue.cs Keen.NetStandard/IDynamicPropertyValue.cs Keen.NetStandard/IEvent.cs Keen.NetStandard/IEventCache.cs Keen.NetStandard/IEventCollection.cs Keen.NetStandard/IHttpClientProvider.cs Keen.NetStandard/IKeenHttpClient.cs Keen.NetStandard/IKeenHttpClientProvider.cs Keen.NetStandard/IProjectSettings.cs Keen.NetStandard/KeenConstants.cs Keen.NetStandard/KeenException.cs Keen.NetStandard/ProjectSettingsProvider.cs

Are these files enough to setup a basic Project?If not, I would be glad to add. And Regarding the Test Project, I didn't find any Test files on the above-said files in the .Net. I'm actually a newbie to Unit-Testing. So, Explanation on this would be helpful.

Sorry If I'm taking much of your time. Thank You.

masojus commented 6 years ago

At first glance, this seems like a great start. Thank you! I'll dig in a little deeper, but with regard to the testing aspect of it, we could get this merged first so we can keep moving and meanwhile since you'd expressed interest in Issue #74 you could look at the existing test projects for guidance and try to use nunit+Moq to do something like just create an instance of CachedEvent, KeenException or ProjectSettingsProvider and validate internal consistency.

For example, verify that creating a ProjectSettingsProvider works with default inputs, like the keenUrl being null, and have another test ensure that it works with a non-null keenUrl and maintains the custom base authority. These are pretty slim tests in that those classes don't do a lot of processing on their fields, but it would serve to prove the concept and get all the scaffolding in place to party on the test project and really flesh out our test coverage as we port more features.

masojus commented 6 years ago

Oh, and I'll take a look at the CI failure...I didn't really ever expect it to work the first time with a new netstandard2.0 project. We're just getting this CI and code coverage stuff in place and part of that is adapting it to building and verifying for both .NET Framework and .NET Standard--that's partly why I'm so interested in having a test project in place as soon as we can just to fix up the CI and coverage scripts to handle running those. Thanks for helping and sorry you're seeing those "AppVeyor build failed" messages :)

https://blogs.msdn.microsoft.com/seliot/2011/04/25/i-dont-always-test-my-code-but-when-i-do-i-do-it-in-production/

Pothulapati commented 6 years ago

I will look at the .Net Framework tests to understand whats happening in there. I will then add some tests for the classes that are added to the .Net Standard Library. Sounds Fun 👍

Thank You :)

masojus commented 6 years ago

I'll likely merge this tonight, or if not tomorrow. Thanks again!

masojus commented 6 years ago

I have some tooling issues referencing this from console apps in my current version of VS2017, but it all seems to work fine when I write a test app and build/run using the dotnet cli so I'm going to go ahead and merge this so we can keep moving forward.