We Keep Coding

Debugging a React app from console as if the console was the app itself

When I used to program with python I could run a python app and then execute methods and access variables of the app from within terminal. This was a great way to test things around.
Working on my JS app I often use console.log to try things out but I am looking for a way to try things without having to rerun the app each time. I want to be able to call any method / variable of my React app (including imported classes etc) from within console "at run-time".
Is this possible? If yes, how?
If not, what is the best alternative to switching between code and browser back-and-force to see the effect of certain changes console.log ?

Using AudioContext in unit tests

I am developing a JavaScript library (https://github.com/yvesgurcan/web-midi-player) to enable MIDI playback in a web application. The library relies on the Web Audio API to create a way to play these MIDI files (https://github.com/yvesgurcan/web-midi-player/blob/test/src/MidiPlayer.js#L50). However, I am having trouble creating meaningful unit tests with Jest (https://github.com/yvesgurcan/web-midi-player/blob/test/tests/midiPlayer.js) because these tests don't have access to the window object and more particularly to window.AudioContext. As a consequence, running my application code which relies on AudioContext throws errors related to the fact that this object does not exist and I can't actually test very much things in the library.
I've tried the following packages to solve my problem: jsdom, jsdom-global, and also web-audio-test-api but none of these seem to inject AudioContext in the environment.
I am thinking that the solution here would be to stub/mock AudioContext but that does not sound like a good solution for solid unit tests.
What do you folks suggest to test the Web Audio API? Is stubbing the only viable solution here?

I think it depends a bit on what you want to test. Since you're using Jest I imagine you're just interested in testing the correctness of your own code. In that case I would recommend to fully mock the Web Audio API. It's not part of your responsibility and you can assume it works the way it should. The only thing you have to test is if your code is making the expected calls.
Mocking globally available variables like the AudioContext constructor is always a bit tricky but you could allow an AudioContext to be passed into your MidiPlayer class as an optional argument. It would make testing a little easier and it would also allow users of your library to bring their own AudioContext.
I think of something like this:
class MidiPlayer {
constructor({
// ... the other options ...
context = new AudioContext()
}) {
// ...
}
}
Inside a test you could then simply instantiate the MidiPlayer with a fake AudioContext.
const fakeAudioContext = {
currentTime: 3,
// ... and all the other things your code uses ...
};
const midiPlayer = new MidiPlayer({ context: fakeAudioContext });
I recently answered a similar question related to Tone.js which might be helpful. The basic idea is the same.
In case you want to test if your library works nicely with the Web Audio API in a browser I would recommend to use a test runner like Karma. It executes the tests in a real browser and therefore can use all the browser APIs.

Protractor is executing onPrepare multiple times in multicapability mode

I am newbie to protractor and javascript. I am trying to execute several tests in parallel using multiCapabilities. However when I do this onPrepare or beforeAll are all executing once per every spec. Is there a way to execute onPrepare and onComplete only once for all tests?
I am facing this issue in two situations. 1. Different browsers. 2. Same browser with multiple instance i.e., as follows. capabilities : { browserName : 'chrome', shardTestFiles : true, maxInstances : 2 }, In both cases my code under onPrepare is executing twice. I have a requirement to write the test result of each test to a Json file and I am creating new file in onPrepare and it is getting over written when I use maxinstances > 1

When you are running your protractor test cases with multi capability option, Then the onPrepare method will be executed for each set of capability you have mentioned in multi capabilities object (i.e) Sharded tests run in a different process.
In you case, you need to create your test report file in beforeLaunch method. This method will execute only once before initializing protractor global objects.
Kindly refer https://github.com/angular/protractor/blob/master/lib/config.ts#L404 for additional details on beforeLaunch method.

Running multiple instances of selenium webdriver asynchronously (firefox)

How can I make my webdriver request multiple pages (or open multiple browsers) at the same time, concurrently?
All solutions I found on the internet waits until the previous session has finished loading and only then open a new instance of the browser.
I have tried selenium-webdriver, webdriverjs and wdjs, and none of them seem to be able to do multiple http requests for different pages asynchronously. Even solutions like this https://github.com/OniOni/wd-parallel-async wont work. They all open one at time.
Am I missing something?
PS: I don't want to run multiple browsers concurrently! I want to run multiple instances of the same browser.

Something like:
WebDriver driver1 = new FirefoxDriver();
WebDriver driver2 = new FirefoxDriver();
WebDriver driver3 = new FirefoxDriver();
driver1.get("page1");
driver2.get("page2");
driver3.get("page3");
If you need it truly asynchronous, then you will need to get into Java threading ... which would make this into a longer discussion and off-topic for SO.

Utilize threading. I see you have node.js tagged...I am not as familiar with that, but below is a c# example that works...similar theory should apply.
c#
Parallel.Invoke(
()=> { 1st test execution call },
()=> { 2nd test execution call },
()=> { 3rd test execution call }
);
Although be careful as the webdriver can sometimes get confused and overlap windows. I have found that doing more than 5 at a time on a single machine leads to miscellaneous problems. If you use the Parallel.Invoke in c# you can throttle this to only allow a certain number at a time...although Grid is the best way to do that as you setup your limits in configuration and then it load balances for you.

JavaScript Unit Testing integrated with CruiseControl.NET

I'm looking for framework which provides unit tests for JS. Later, I'll have to integrate it with CruiseControl.NET. I have a lot of asp websites using JS and I need to automate testing for them. For example I used local JSUnit (may be other framework), which was quite easy for me, but I have no idea how to integrate it with CC.NET. Maybe you can show me how to start with ?
NOTE: it must be CC.NET, framework for unit test not specified

I realize this is a rather old question, but I have had similar interests so I figure I would post an answer regardless. I am assuming you are writting OO style JavaScript and wanting to test those objects.
A common solution recommended by people is to run JsTestDriver and this is definitely a great tool; that being said, it requires the JVM to be installed on your machine as well as the build server. In addition to requiring the JVM, JsTestDriver is still dependant on running one or more 'Slave' browsers. Personally, I believe that should not be a concern when unit testing JavaScript objects. If the focus is UI testing, then using a tool such as WatiN and is a different type of test in my opinion. The browser should be mock out like you would mock out any other view using JSMock or JsMockito (which I like best).
To that end, I have used Windows Script Host to run my JavaScript unit tests for years. This has several advantages:
No Browser Required (to me that is a good thing).
CScript is already on every Windows machine since XP; so nothing to install.
Runs in background process and does not require an interactive UI when running tests.
Since running inside MSTest, NUnit or xUnit etc, integrating with CC.NET, Hudson, or TeamCity is as easy as running your unit tests as a part of the build.
Full debug support simply by running your unit test inside the debugger.
There are a couple of disadvantages of course:
The machine running the unit tests has to have the ability to spawn off new processes (CSCript) to actually run the tests (has yet to be an issue).
Slower that running regular unit tests (A little over 1,000/minute on an older dual core if run individually - i.e., not bundled together in a single CSCript process).
Using JSTest.NET (approach I have used for years but just posted online), you end up with a test fixture that may look similar to the following:
using JSTest;
using JSTest.ScriptLibraries;
using Xunit;
namespace JSTest.Sample
{
public class EventDispatcherTests
{
private readonly TestScript _testScript = new TestScript();
public EventDispatcherTests()
{
//Append File(s) Under Test.
_testScript.AppendFile(#"..\..\..\Web\Scripts\eventDispatcher.js");
//Append Mock/Assertion libraries.
_testScript.AppendBlock(new JsHamcrestLibrary());
_testScript.AppendBlock(new JsMockitoLibrary());
//Append Common "Setup" Scripts.
_testScript.AppendBlock(#"var dispatcher = new EventDispatcher();
var mockHandler = JsMockito.mockFunction();
var mockPredicate = JsMockito.mockFunction();
var fakeEvent = { eventType: 'CommentAdded', data: 'Sample Comment' };
");
}
[Fact]
public void ProcessEventInvokesAttachedHandler()
{
...
}
[Fact]
public void ProcessEventGracefullyHandlesPredicateException()
{
_testScript.RunTest(#"var mockPredicateAlternate = JsMockito.mockFunction();
JsMockito.when(mockPredicateAlternate)(fakeEvent).thenThrow('MyException');
dispatcher.attachListener(mockHandler, mockPredicateAlternate);
dispatcher.processEvent(fakeEvent);
JsMockito.verify(mockPredicateAlternate)(fakeEvent);
JsMockito.verifyZeroInteractions(mockHandler);
");
}
}
}
This approach works well for me, and is very simple to setup. Basically, it is like writing regular unit tests, but with JavaScript.