When I tried to do unit testing for private methods in a Class getting error as private methods are only accessible inside the class. Here I added sample snippet for my class and mocha test. Kindly provide me solution to implement unit test for private methods.
Class Name: Notification.ts
class Notification {
constructor() {}
public validateTempalte() {
return true;
}
private replacePlaceholder() {
return true;
}
}
Unit Test:
import {Notification} from 'Notification';
import * as chai from "chai";
describe("Notification", function(){
describe('#validateTempalte - Validate template', function() {
it('it should return success', function() {
const result = new Notification()
chai.expect(result.validateTempalte()).to.be.equal(true);
});
});
describe('#replacePlaceholder - Replace Placeholder', function() {
it('it should return success', function() {
const result = new Notification()
// As expected getting error "Private is only accessible within class"
chai.expect(result.replacePlaceholder()).to.be.equal(true);
});
});
});
As a workaround, currently, I am changing access specifier of function replacePlaceholder to public. But I don't think its a valid approach.
A possible solution to omit Typescript checks is to access the property dynamically (Not telling wether its good).
myClass['privateProp'] or for methods: myClass['privateMethod']()
Technically, in current versions of TypeScript private methods are only compile-time checked to be private - so you can call them.
class Example {
public publicMethod() {
return 'public';
}
private privateMethod() {
return 'private';
}
}
const example = new Example();
console.log(example.publicMethod()); // 'public'
console.log(example.privateMethod()); // 'private'
I mention this only because you asked how to do it, and that is how you could do it.
Correct Answer
However, that private method must be called by some other method... otherwise it isn't called at all. If you test the behaviour of that other method, you will cover the private method in the context it is used.
If you specifically test private methods, your tests will become tightly coupled to the implementation details (i.e. a good test wouldn't need to be changed if you refactored the implementation).
Disclaimer
If you still test it at the private method level, the compiler might in the future change and make the test fail (i.e. if the compiler made the method "properly" private, or if a future version of ECMAScript added visibility keywords, etc).
In my case, I use the prototype of the object to get access to a private method. It works well and TS does not swear.
For example:
class Example {
private privateMethod() {}
}
describe() {
it('test', () => {
const example = new Example();
const exampleProto = Object.getPrototypeOf(example);
exampleProto.privateMethod();
})
}
If you use a static method then use exampleProto.constructor.privateMethod();.
In HolgerJeromin's comment, the comment issue has a succinct solution that still uses the property syntax.
The solution is to type cast your object / class to any.
Examples:
(<any>myClass).privateMethod();
const value = (<any>myClass).privateValue;
(myClass as any).privateMethod();
const value = (myClass as any).privateValue;
This method satisfies the compiler as well as the VSCode syntax highlighting.
Here are some of my notes from the issue that talks about this
Accessing via a string is more common, although I don't see why it might be more typesafe.
These features are done deliberately, therefore they are helping more than hindering.
There is probably a way to disable this type of feature so people don't copy and paste this code into production. "noImplicitAny": true, might help in the tsconfig.json
Extract out the private function into a separate/stand alone function, but don't export it externally.
This is somewhat semantically correct, since after all — a private function is private and should not be accessed by anyone except the class itself.
My subjective solution: you could define a new testing-only interface that extends the original one by adding the private methods as (implicitly public) interface methods. Then, you cast the instantiated object to this new test type. This satisfies both tsc and VS code type checking. Your example with my solution:
interface INotification {
validateTemplate(): boolean,
}
class Notification implements INotification {
constructor() {}
public validateTemplate() {
return true;
}
private replacePlaceholder() {
return true;
}
}
Testing:
import {Notification} from 'Notification';
import * as chai from "chai";
interface INotificationTest extends INotification {
replacePlaceholder(): boolean;
}
describe("Notification", function(){
describe('#validateTemplate - Validate template', function() {
it('it should return success', function() {
const result = new Notification() as INotificationTest;
chai.expect(result.validateTemplate()).to.be.equal(true);
});
});
describe('#replacePlaceholder - Replace Placeholder', function() {
it('it should return success', function() {
const result = new Notification() as INotificationTest;
// Works!
chai.expect(result.replacePlaceholder()).to.be.equal(true);
});
});
});
Advantages:
tsc and vs code do not complain
IntelliSense (or any other autocomplete) works
simple (subjectively)
If you don't want to define the original interface (INotification), you could just fully define the test one (INotificationTest) instead of extending and cast it in the same manner.
Disadvantages:
Added boilerplate
Need to have both of the interfaces updated and in sync
Potentially introducing bugs by explicitly casting as a non original type.
I leave it up to you to decide whether this is worth it or no. In my case, the positives outweigh the negatives. I have tested this with jest, but I assume that mocha.js is no different here.
Edit: but generally I would agree with Fenton's answer
// module.ts
private async privateMethod = () => "private method executed"
public async testPrivateMethods(...args) {
if (process.env.NODE_ENV === 'development') {
return this.privateMethod(...args);
}
}
Now we can reach our private method to test. In jest file:
// module.spec.js
describe('Module', () => {
let service: Module = new Module();
it('private method should be defined', () => {
expect(service.testPrivateMethods).toBeDefined();
});
}
You need to set your enviroment variable name of NODE_ENV must be development.
// .env
NODE_ENV="development"
The fun thing is that it's just a typescript error (not javascript), so you can fix it with
// #ts-expect-error
and everything works fine.
I consider it as a legitimate solution, as the goal was to suppress typescript in this particular case.
Since private methods are not accessible outside class, you can have another public method which calls replacePlaceholder() in Notification class and then test the public method.
I know this is kind of a weird question, but I would like to mock an inner require(); statement in a constructor. This is my test file:
import { PiControl } from "../pi";
describe("PiControl", () => {
beforeEach(() => {
this.piControl = new PiControl();
});
it("Should initialise the control and call the board ready event.", () => {
expect(true).toBe(true);
});
});
As you can see below, I'm instantiating the class PiControl and when I run my test and make an instance of the PiControl.
export class PiControl extends BaseControl {
public board: any;
constructor() {
super();
// No idea if this can be mocked, but I would like to.
const Raspi = require("raspi-io");
const five = require("johnny-five");
const board = new five.Board({
io: new Raspi({ enableSoftPwm: true }),
});
this.board = board;
}
public loadControl(): void {
this.board.on("ready", this.setupMotors);
}
}
As you can see below, that is what the test outputs. It will call the original library (which is supposed to run on a Raspberry PI) and tries to run it on my development machine.
Question: is there a way to workaround this issue?
For what it's worth, I'm testing the whole application using Jest (almost out-of-the-box config).
I am trying to use Shim to test one of my private method in this class called DataSyncCore.
Apologies if this is too trivial as i am new to shims and can't figure out why this is giving me an error saying "The property or indexer GetEnvironmentString cannot be used in this context as it is lacking an accessor. How can this be fixed?
//Method to be tested inside DataSyncCore Class
private Environments GetEnvironment(string env)
{
string environment = env.ToLower();
switch (environment)
{
case "dev":
return Environments.Dev;
case "qc":
return Environments.QC;
case "uat":
return Environments.UAT;
case "prod":
return Environments.PROD;
default:
return Environments.Dev;
}
}
This is my unit test:
[TestMethod]
public void DataSyncCore_GetsEnvironment_Succeeded()
{
using (ShimsContext.Create())
{
var core = new ShimDataSyncCore()
{
GetEnvironmentString = (dev) =>
{
return Environments.Dev;
}
};
Assert.AreEqual(Environments.Dev, core.GetEnvironmentString("dev"));
}
}
If you cannot make the class public, you can still use Activator.CreateInstance:
var anInstance = (YourPrivateClass)Activator.CreateInstance(typeof(YourPrivateClass), true);
Or, you could mark the method as internal and set InternalsVisibleTo attribute in your assemblyinfo if you want/need to test that method directly.
In my grails application, in the controller, I use following kind of a thing :
class SampleController {
def action1 = {
def abc = grailsApplication.getMetadata().get("xyz")
render abc.toString()
}
}
While running the app, it correctly reads the property "xyz" from application.properties and works fine. But when I write a unit test case for the above controller as follows :
class SampleControllerTests extends ControllerUnitTestCase {
SampleController controller
protected void setUp() {
super.setUp()
controller = new SampleController()
mockController(SampleController)
mockLogging(SampleController)
}
void testAction1() {
controller.action1()
assertEquals "abc", controller.response.contentAsString
}
}
But when I do "grails test-app", I expect that it will pick up the property "xyz" from application.properties and will return as expected. But it gives error as "No such property : grailsApplication".
I understand, I guess I need to mock grailsApplication object and I tried many of the options also But all those didn't work.
I am new to Grails.
mockController will not mock the GrailsApplication, you will need to do it yourself.
The fastest solution would be something like:
protected void setUp() {
super.setUp()
mockLogging(DummyController)
GrailsApplication grailsApplication = new DefaultGrailsApplication()
controller.metaClass.getGrailsApplication = { -> grailsApplication }
}
This solution is not perfect - it will create a new DefaultGrailsApplication during each setup and mockController also creates some additional instances of DefaultGrailsApplication.
Note that you do not need to call mockController by yourself it will be done by the ControllerUnitTestCase for you.
im looking for something similar to what i would do with rhino mocks but in groovy.
i sometimes use partial mocks as well.
in ASP -- Rhino mocks
const string criteria = "somecriteriahere";
ISomeRepository mockSomeRepository = MockRepository.GenerateStrictMock<SomeRepository>();
mockSomeRepository.Expect(m => m.GetSomesByNumber(criteria)).Return(new List<Some>() { });
mockSomeRepository.Expect(m => m.GetSomesByName(criteria)).Return(new List<Some>() { });
mockSomeRepository.Expect(m => m.GetSomesByOtherName(criteria)).Return(new List<Some>() { });
mockSomeRepository.SearchForSomes(criteria);
mockSomeRepository.VerifyAllExpectations();
--------note the virtual -------
public class SomeRepository : ISomeRepository {
public virtual IEnumerable<Some> GetSomesByNumber(string num)
{
//some code here
}
public virtual IEnumerable<Some> GetSomesByName(string name)
{
//some code here
}
public virtual IEnumerable<Some> GetSomesByOtherName(string name)
{
//some code here
}
public IEnumerable<Some> SearchForSomes(string criteria) {
this.GetSomesByNumber(criteria); //tested fully seperatly
this.GetSomesByName(criteria); //tested fully seperatly
this.GetSomesByOtherName(criteria); //tested fully seperatly
//other code to be tested
}
}
GetSomesByNumber, GetSomesByName, GetSomesByOtherName would be tested fully seperatly. If i actually provided values and went into those functions, to me, that seems like in integration test where im testing multiple functionalities and not one unit of work.
So, SearchForSomes i would only be testing that method and mocking away all other dependencies.
In Grails
class XService {
def A() {
}
def B() {
def result = this.A()
//do some other magic with result
}
}
I have tried this -- but failed
def XServiceControl = mockFor(XService)
XServiceControl.demand.A(1..1) { -> return "aaa" }
// Initialise the service and test the target method.
//def service = XServiceControl.createMock();
//def service = XServiceControl.proxyInstance()
// Act
//def result = XServiceControl.B(_params);
XServiceControl.use {
new XService().B(_params)
}
Ive got no idea how to do this, does any one know how?
Thanks
If you're using groovy MockFor (e.g. groovy.mock.interceptor.MockFor), then you need to enclode the usage in a .use{} block.
However, it looks like you are calling mockFor from within a grails.test.GrailsUnitTestCase. In that case, there's no need for the .use{} block: the scope of the mock is the whole test.
thanks for your reply ataylor
seem what i was trying to accomplish is something called partial/half mocking. Here are some links.
http://www.gitshah.com/2010/05/how-to-partially-mock-class-and-its.html
http://mbrainspace.blogspot.com/2010/02/partial-half-mocks-why-theyre-good-real.html
https://issues.apache.org/jira/browse/GROOVY-2630
https://issues.apache.org/jira/browse/GROOVY-1823
http://java.dzone.com/articles/new-groovy-171-constructor
I didnt accomplish this, i ended up extracting B() into its own class and injecting a mock of XService into B's class -- Dependency Injection. I was also informed that extracting away dependencies is a better practice for testing. So, i am now very carefull when using this.() :D