MD WebUI: attempt to clean up file paths on vulcanize+Windows

chrome/browser/resources/vulcanize_gn_test.py

+#!/usr/bin/env python
+# Copyright 2017 The Chromium Authors. All rights reserved.
+# Use of this source code is governed by a BSD-style license that can be
+# found in the LICENSE file.
+
+import os
+import shutil
+import tempfile
+import unittest
+import vulcanize_gn
+
+
+_HERE_DIR = os.path.dirname(__file__)
+
+
+class VulcanizeGnTest(unittest.TestCase):
+  def setUp(self):
+    self._out_folder = None
+    self._tmp_dirs = []
+    self._tmp_src_dir = None
+
+  def tearDown(self):
+    for tmp_dir in self._tmp_dirs:
+      shutil.rmtree(tmp_dir)
+
+  def _write_file_to_src_dir(self, file_name, file_contents):
+    if not self._tmp_src_dir:
+      self._tmp_src_dir = self._create_tmp_dir()
+    with open(os.path.join(self._tmp_src_dir, file_name), 'w') as tmp_file:
+      tmp_file.write(file_contents)
+
+  def _create_tmp_dir(self):
+    # TODO(dbeam): support cross-drive paths (i.e. d:\ vs c:\).
+    tmp_dir = tempfile.mkdtemp(dir=_HERE_DIR)
+    self._tmp_dirs.append(tmp_dir)
+    return tmp_dir
+
+  def _read_out_file(self, file_name):
+    assert self._out_folder
+    return open(os.path.join(self._out_folder, file_name), 'r').read()
+
+  def _run_vulcanize(self, args):
+    # TODO(dbeam): make it possible to _run_vulcanize twice? Is that useful?
+    assert not self._out_folder
+    self._out_folder = self._create_tmp_dir()
+    vulcanize_gn.main(args + [
+      '--host', 'fake-host',
+      '--input', self._tmp_src_dir,
+      '--out_folder', self._out_folder,
+    ])
+
+  def testSimpleVulcanize(self):
+    self._write_file_to_src_dir('element.html', '<div>got here!</div>')
+    self._write_file_to_src_dir('element.js', "alert('yay');")
+    self._write_file_to_src_dir('ui.html', '''
+<link rel="import" href="element.html">

[dpapad, 2017/02/07 03:00:32]

That's a good start. I think it would be valuable to test the effect of the
--redirect flags. Also I think instead of making specific toy assertions in the
generated file, a much more common pattern I have encountered (more than once)
for testing the code generators is the following:

 1) Use dummy input files (element.html, element.js, ui.html).
 2) Run the tool being tested, and commit the output as the ground truth.
 3) When asserting, just assert the entire contents of the file match the ground
truth.
 4) When making changes to the generation script, need to update the ground
truth (after
    manually inspecting that the diff between previous truth and new one is
correct).

[Dan Beam, 2017/02/07 03:02:39]

#patcheswelcome, I named this "simple" for a reason

[dpapad, 2017/02/07 03:44:21]

I was not implying to do this in this CL. Mostly I wanted to see WDYT about that
approach. I am interpreting #patcheswelcome as a "SGTM".

+<script src="element.js"></script>
+''')
+
+    self._run_vulcanize(['--html_in_file', 'ui.html',
+                         '--html_out_file', 'fast.html',
+                         '--js_out_file', 'fast.js'])
+
+    fast_html_css = self._read_out_file('fast.html')

[dpapad, 2017/02/07 03:00:32]

I am confused by the '_css' suffix. Aren't we just reading the contents of the
generated HTML file here? If so why not naming this |fast_html| or
|fast_html_contents|?

[Dan Beam, 2017/02/07 03:02:39]

fixed in updated patch

+    self.assertFalse('element.html' in fast_html_css)
+    self.assertFalse('element.js' in fast_html_css)
+    self.assertTrue('got here!' in fast_html_css)
+
+    fast_js = self._read_out_file('fast.js')
+    self.assertTrue('yay' in fast_js)
+
+
+if __name__ == '__main__':
+  unittest.main()