They wouldn't fill a post
Memory leaks can lead a quiet life. They won't inform us of their occurrence, but if we have observed long enough how a machine performs under a variety of circumstances and loads, we start to develop an intuitive feeling of when things could be slowing down due to a memory leak. If we don't pay attention to the machine, we would need to open the task manager anytime we suspect strange behavior. This interrupts our work and consumes additional resources as well.
Although I was aware of a tool like Selenium, I was reluctant to use it for a long time as I didn't find it convenient enough for frequent use. Combining it with phpUnit required much more code than I was willing to write or able to track. My opinion about it still hasn't changed radically, but at least I found a way to test it. Selenium can direct the browser to a chosen URL and perform automated keyboard and mouse actions on preselected page elements. We can select them by tag name, id, CSS or even XPath. Unit tests can helps us track whether the browser responded to the event in an expected manner. Selenium can work with most browsers which may also help to identify browser-specific bugs (although we shouldn't be writing our code in a way that causes them). It supports phantomJS—a headless browser that remains hidden from us, but is still able to type and click on any element on the page. This means that, in theory, we should be able to execute our tests faster, but without seeing the results visually (and whether things worked as we wanted them to look). We have to rely entirely on the correctness of the unit tests—something which is not easy to guarantee. PhantomJS worked as expected and I saw some tests passing and others failing. But then I noticed that my PC started to slow down although I was “closing” the driver instance at the end of the script. The task manager showed many instances of PhantomJS running, each one taking approx. 60MB memory. It turned out that other people were already discussing the memory leaks with PhantomJS on StackOverflow. After spending some time on individual process killing, I was convinced that invoking a Firefox instance might be a better choice. This time everything worked, the browser started (with a bit over 80MB memory cost), some actions were executed and I was even able to see their effect. But everything happened so fast, that I could barely see it. Now I needed to introduce some waiting time in order to see exactly what was happening, but this meant to write even more code. I found that the 20MB additional memory cost was well worth for the increased stability and visual control it allowed, but your requirements may call for another option. A common error I had was the StaleElementException, which occurs when actions are executed in order, where we have preselected all elements we want to work with in advance, but an action changes the page in a way that invalidates the references to the rest of the elements. A possible solution to this seemed to be either to select only the element which would be immediately acted upon or use an action chaining API specifically for this task.
Stanford University and Ycombinator have started a course called “How to start a startup” that might be interesting for you. All videos are publicly available without registration, which supports a more open web. Although there are many interesting points, Sam Altman has warned at the start that some of the advice may or may not work for you, depending on your situation. This is why without questioning, automatic acceptance of any advice would be wrong. Recently, Peter Thiel said: “Begin by studying the end game”, but this isn't how most people tend to think. We expect everything to be fast and smooth, but the reality is that it takes many years before the first fruits of effort start to show. We need to prepare ourselves for the future and anticipate it or at best, any success will only be temporary. Another interesting lecture.