szaszm commented on a change in pull request #821:
URL: https://github.com/apache/nifi-minifi-cpp/pull/821#discussion_r447110192



##########
File path: extensions/standard-processors/tests/unit/RetryFlowFileTests.cpp
##########
@@ -0,0 +1,221 @@
+/**
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *     http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#define CATCH_CONFIG_MAIN
+
+#include <memory>
+#include <string>
+#include <set>
+#include <regex>
+
+#include "TestBase.h"
+
+#include "processors/GenerateFlowFile.h"
+#include "processors/UpdateAttribute.h"
+#include "processors/RetryFlowFile.h"
+#include "processors/PutFile.h"
+#include "processors/LogAttribute.h"
+#include "utils/file/FileUtils.h"
+#include "utils/OptionalUtils.h"
+#include "utils/TestUtils.h"
+
+namespace {
+using org::apache::nifi::minifi::utils::createTempDir;
+using org::apache::nifi::minifi::utils::optional;
+
+std::vector<std::pair<std::string, std::string>> list_dir_all(const 
std::string& dir, const std::shared_ptr<logging::Logger>& logger, bool 
recursive = true) {
+  return org::apache::nifi::minifi::utils::file::FileUtils::list_dir_all(dir, 
logger, recursive);
+}
+
+class RetryFlowFileTest {
+ public:
+  using Processor = org::apache::nifi::minifi::core::Processor;
+  using GenerateFlowFile = 
org::apache::nifi::minifi::processors::GenerateFlowFile;
+  using UpdateAttribute = 
org::apache::nifi::minifi::processors::UpdateAttribute;
+  using RetryFlowFile = org::apache::nifi::minifi::processors::RetryFlowFile;
+  using PutFile = org::apache::nifi::minifi::processors::PutFile;
+  using LogAttribute = org::apache::nifi::minifi::processors::LogAttribute;
+  RetryFlowFileTest() :
+    logTestController_(LogTestController::getInstance()),
+    
logger_(logging::LoggerFactory<org::apache::nifi::minifi::processors::RetryFlowFile>::getLogger())
 {
+    reInitialize();
+  }
+  virtual ~RetryFlowFileTest() {
+    logTestController_.reset();
+  }
+
+ protected:
+  void reInitialize() {
+    testController_.reset(new TestController());
+    plan_ = testController_->createPlan();
+    logTestController_.setDebug<TestPlan>();
+    logTestController_.setDebug<GenerateFlowFile>();
+    logTestController_.setDebug<UpdateAttribute>();
+    logTestController_.setDebug<RetryFlowFile>();
+    logTestController_.setDebug<PutFile>();
+    logTestController_.setDebug<PutFile>();
+    logTestController_.setDebug<LogAttribute>();
+    logTestController_.setDebug<core::ProcessSession>();
+    logTestController_.setDebug<core::Connectable>();
+    logTestController_.setDebug<minifi::Connection>();
+  }
+

Review comment:
       There are no rules against ASCII art that I know of. I previously 
expressed that I didn't like them personally, but at the end of the discussion 
the conclusion was that they provide value to the reader, therefore they are 
useful.
   
   I am just a contributor to the project and I happened to contribute many 
reviews lately, because I believe ensuring that no easily preventable issues 
are committed, and the code is of the highest quality obtainable with relative 
ease is usually the most efficient use of my time. I believe it provides more 
value on the long term by enabling contributors (myself and others) to work 
with the code more effectively.
   
   Having said that, my opinions and review suggestions are my attempt at being 
helpful, not rules. I think they become de jure rules when someone proposes it 
and the community agrees. On the other hand, they may easily become de facto 
"rules", that is, if I (or anybody) made a suggestion that improved code in 
some way, then I would expect the same contributors to try to submit an already 
"improved" version of similar code in their future contributions. I usually 
consider de facto "rules" conventions rather than rules.
   
   I'm writing this because I don't want you or any contributors to be 
discouraged by my past reviews.
   
   tl;dr: my comments are not rules




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Reply via email to