Salesforce : Enable 75% test coverage while deployment in DE org - unit-testing

I'm using sfdx to deploy my components and classes to a developer edition org, but while deploying it doesn't check 75% test coverage of apex classes, is there any setting to enable test coverage while deployment or DE Org doesn't support test coverage checks while deployment?

You can deploy to developer edition / trailhead playground orgs without code coverage or edit apex straight in "prod" (in setup or developer console). Developer Editions have no sandboxes and concept of scratch orgs is relatively new so being able to work in "prod" was the only option. Plus well, it helps with rapid prototyping of ideas without the "hurdle" of unit tests.
If you'd be eventually making a managed package - don't worry. During process of packaging new version you'd have the usual checks (does everything compile, do all tests pass, 75% overall and at least 1% on triggers).
You can choose to run local tests while deploying but I don't think there's native way to enforce 75% threshold. Maybe something in your CI tool could help (GitHub actions or what have you)

Related

Scope of Integration Testing in a CI CD workflow

The question is more about the fundamental understanding of a normal/ideal CI flow and understanding the scope of integration testing in it.
As per my understanding, the basic CI CD flow is
UnitTesting --> IntegrationTesting --> Build Artifact --> Deploy to Dev/Sandbox or any other subsequent environments.
So unit tetsing and integration testing collectively decide/make sure if the build is stable and ready to be deployed.
But, recently, we had this discussion in my team where we wanted to run integration tests on deployed instances on Dev/Sandbox etc , so as to verify if the application is working fine after deployment.
And the microsoft's article on Build - Deploy - Test workflows suggests that this could be a possible way.
So , my questions are :-
Are integration tests supposed to test configuration of different environments ?
Are integration tests supposed to be run before packaging application or deploying the application ?
If at all, some automated testing is required to test deployed application functioning on all environments ?
If not integration tests then what could be alternative solutions
You're mixing Integration testing with System testing.
Integration testing checks that some components can work together (can be integrated). You may have integration tests to verify how does the Data layer API operates with a database; or how does the the Web API responds to HTTP calls. You might not have the entire system completely working in order to do integration testing of its components.
Unlike integration tests, the System tests require all the components to be implemented and configured. That is end-to-end testing (e.g. from a web request to a database record). This kind of testing requires the entire system to be deployed which makes them more 'real' but expensive.

How can I speed up my unit tests using cloud computing?

I work on a project with a lot of legacy code that has some tests (in JUnit). Those unit tests are pretty slow and running them often slows me down. I plan on refactoring and optimizing them (so they're real unit tests), but before I do this, I'd like to speed them up just for now, by running them in parallel. Of course I could get myself some cluster and run them there, but that's not worth the hassle and the money. Is it possible to do so with some cloud services like e.g. Amazon AWS? Can you recommend me some articles where I could read more about it?
Running unit tests in parallel requires 2 things:
Creating groups of multiple tests using either suites or JUnit categories
A way to launch each group of tests
Once you have #1, an easy way to get #2 is to use Continuous Integration.
Do you already use Continuous Integration ?
If not, it is easy to add. One of the more popular ones is Jenkins
Jenkins also supports distributed builds where a master code launches build jobs on slave nodes. You could use this to run each of your groups in parallel.
Continuous Integration in the Cloud
Once you have Continuous Integration set up, you can move it into the cloud if you wish.
If you want to stick with jenkins, you can use
Cloud Bees which costs money
Red Hat Openshift "Gears" can be used to run Jenkins. I think it is possible to use gears in Amazon WS but I've never done it. You can run a few gears with limited memory usage for free, but if you need more it will cost money.
If you don't want to use Jenkins, there are other cloud based CIs including
Travis-CI which integrates with github. Here is an article about how to speed up builds in Travis

Sauce Labs alternative

We're looking into automating our web UI using either Microsoft's coded UI tests or Telerik TestStudio framework. I would love to run our tests using a service like Sauce Labs however, Sauce Labs requires Selenium tests. Is anyone aware of some service similar to Sauce Labs to run web tests other than Selenium?
TFS in the cloud looks promising http://tfspreview.com/
Regardless of TFS service or Sauce Lab, be aware that a service only frees you the burden of maintaining a CI/Test server in house. It doesn't magically generate tests for you. It's still your responsibility to design and code many tests. That is where huge effort and learning curve will take place.
(Speaking of learning curve, Selenium is much more manageable than Ms coded ui test. Wait for chances to influence company decision...)
Sauce Labs in fact is able to run other (Non-Selenium & Appium) frameworks. There is a testrunner that is super easy to use called saucectl. You can test with CYpress, Test Cafe, Espresso, XCUITest and more. You can see the info in the docs.
TLDR
Install saucectl in your project with cURL or npm install -g saucectl
Setup the runner in your test project with saucectl init. choose your framework flavor and preferences
Run your tests with the
command saucectl run
TFS is not an alternative to Sauce. In fact their is now an integration to run Sauce test from Visual Studio Online formerly TFS. Sauce is a testing grid. The closest competitive solution is BrowserStack. But they are not as widely adopted. But it also is selenium based. Telerik TestStudio is nice, but it also is not the cloud you run on. Maintaining your own grid is a huge part of the value of a cloud-based solution. And selenium really is the best and most supported language for doing it.

Adopting Bamboo or TeamCity as native Windows C++ build automation/CI server?

At the moment, we are running our automated (not CI as such) builds via FinalBuilder via a very simple homegrown Apache interface that just launches the FB scripts on our server. (I like FinalBuilder, and will keep it, but it's CI server, FinalBuilder Server just doesn't cut it IMHO -- especially it doesn't support any "agent" concept at the moment to distribute builds across machines.)
We are doing native C++ development on Windows with a bit .NET mixed in where it's needed and makes sense.
Our current FinalBuilder scripts do everything quite well, from creating nightly builds to full releases (build / automated translation / build / unit test / create setup / put created artifacts on a network share / ...), but our webinterface, queuing abilities, user traceability and reporting is pretty limited.
I have looked around and it seems that TeamCity and Bamboo tick similar boxes, but most descriptions I can find cover only Java and/or .NET simple builds.
So my specific question is, given
several (20-30) complicated FinalBuilder Scripts that work to my satisfaction and that I will have to integrate into ("call" from) the new automation/"CI" server
Native Windows C++ and .NET projects
The actual build (= compiler invocation(s)) is done via a few Visual Studio solution files at the moment
Currently one build server machine, wishing to scale to 2-3 atm.
Using JIRA as issue tracker
using AccuRev as SCM
which tool is better suited, and why: TeamCity (currently 6.5) or Bamboo (currently 3.1).
(Note that I also hope to get some highly subjective answers on the TeamCity and Bamboo forums.)
For TeamCity side, it integrates with Jira, has AccuRev plugin, and has a good support for VisualStudio/C++ projects. It can also run arbitrary scripts.
You can trigger a build and obtain some build results via HTTP-based API. In the UI, you can see which changes have been built and in which build configurations. Easily integrate any custom HTML reports into TeamCity UI (no coding), publish artifacts.
Probably, you should try both solutions and see which one is more suitable for you (with Teamcity, you can use full-functional server for free, the only limit is number of build agents and number of build configurations).
Disclaimer: I'm a TeamCity developer
I found Bamboo more credible than TeamCity. Here are my reasons:
Those Jira plugins for VS or Eclipse are Bamboo plug-ins too. :) no extra add-ins needed.
Better support for Jira integration.
Nice user interface, like the one you used for Jira.
Ability to better integration with other Atlassian tools, such as FishEye.
Cheaper. A 10$ license will suffice your company.
More add-ons on Bamboo than TeamCity, lots of plug-ins.
For completeness' sake: I ended up using Jenkins + Finalbuilder. :-)
I worked in a similar environment using FinalBuilder for build automation, AccuRev for source control and a native windows projects.
I ended up selecting Electric Commander as the best CI solution for the job. It is possible to reuse parts of the FinalBuilder scripts and call them from Electric Commander but simply calling the FB script as one build step would result in you missing out on some of the key advantages of using Electric Commander - realtime log file processing, the ability to parallelize right down to individual step levels in Electric Commander and data collection and reporting.
Electric Commander has an API that exposes all product functionality which can be used in combination with AccuRev triggers to achieve a very flexible solution.
Disclaimer - I liked Electric Commander so much I joined the company and am currently employed by Electric Cloud.
You can try Electric Commander by going to www.electric-cloud.com and clicking on "Try It!"

How to setup Continuous Integration and Continuous Deployment for Django projects?

I am researching about how to set up CI and continuous deployment for a small team project for a Django based web application. Here are needs:
Developer check in the code into a hosted SVN server (unfuddle.com)
A CI server detects new checkin, check out the source, build, run functional tests.
If tests all passed, deploy the code to the webserver on Amazon EC2.
For now, the CI server is also responsible to run the functional tests. I figured out that I can use Husdon as the CI server, use Selenium to run functional tests, and use Fabric to deploy the build to remote web server in Amazon cloud.
I am new to Django development and not very familiar with opensource tools. My questions are:
I can find some information to integrate hudson with selenium, but I couldn't find much information on how to integrate Fabric to Hudson as well. Is this setup viable? Do you see problems?
How do I integrate and deploy database changes? Most likely in the early stage we will change database schema very often with code changes. I used to use Visual Studio and the database project made it very simple to deploy. I wonder if there is "established, well-supported" way to do that.
Thanks!!
Can't help you very much with continuous integration/deployment - at my work we used CruiseControl and it acted very much as you describe, but I didn't have anything to do with setting it up.
However in answer to your second question, on database changes, the current state of the art in Django is to use South, which has just released version 0.7. It works well in a CI environment, as db migrations are stored alongside the code for each app, so the CI server can be set to run them automatically before running the tests.