Closed mickaelandrieu closed 9 years ago
Hey @mickaelandrieu, I'm Andy and I'm helping maintain this library.
We built Nightmare with the intention of automating browser tasks, so we aim to keep the exposed methods simple and few. However, it appears that many people are using Nightmare for browser testing. We're considering building a nightmare-testing library that will do just that, while keeping this library simple and for building APIs and plugins.
Let us know what you think of a nightmare-testing library and if you'd like to contribute to it!
Hi @lambtron,
I think we don't need to make another testing library (casperjs'one was a mistake from his creator opinion) but maybe we can work on how to ease the use of major testing libraries (mocha/chai/jasmine/jest) with nigthmarejs.
Then specials plugins/helpers dedicated to use cases like REST consuming/testing can be developped (and I will give a hand).
Like you, I don't want a big API but many useful middlewares: if nightmare offer same features as casperjs I think we wont release after the 1.1.x anymore /c @n1k0
What do you think ?
Hey @mickaelandrieu,
Good points. There are many people using Nightmare for user testing and I think there can be more work done in making it easier for them to do so. Targeting the big testing libraries is a great start. Maybe we can spec out the interface of how users would use Nightmare with Mocha or Jasmine and work from there?
Agree to keep Nightmare simple with many useful middlewares that people can pick and choose. Eventually, I'd also like to see an ecosystem of plugins of automated browser tasks, such as https://github.com/segmentio/nightmare-swiftly
Found this with a quick Google search, using Nightmare with Mocha, Chai for e2e testing: http://weblogs.asp.net/mikaelsoderstrom/writing-end-to-end-tests-with-nightmare-js
How did you imagine you want to improve the testing interface?
[edit] i see you commented on its performance :)
Hi,
I also (like you) experience this bad performance.
Imo the big cost is the instanciation of phantomjs webpage object. In the example you point, a new phantomjs page is instanciated for each test and the timeout is not a good idea at all in this case.
We need a better control on "how" we create, refresh and kill the phantomjs native webpage.
I will present nightmarejs on a (very) little event, so I will experiment it a lot :)
sounds good, we do intend to keep improving nightmare, though we'll keep the API small and push people to develop frameworks around it.
Hi @reinpk,
I'm part of casperjs team and I look at your project since months. As you may notice, casperjs project is a little bit inactive... we don't have time to realy maitain it for now.
Imo, casperjs has some cons:
casperjs have also some pros:
I see that nightmare is actively maintained and I have a lot of ideas to suggest, probably to add fonctionnalities which I have on casper to nightmare.
You said the goal of nightmare is to expose only "few" methods, is there any chance that you change your mind on that ?
Regards,